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ABSTRACT 


This  report  documents  a  review  of  the  technical  ap'  roach  used  to  develop  the  semi- 
automated  forces  (SAFOR)  portion  of  DARPA's  Advanced  Simulation  Technology 
Program.  The  review  was  conducted  in  August  1989  by  an  independent  panel  of  four 
computer  scientists  whose  comments  are  presented  and  summarized.  The  panel  concluded 
that  (1)  the  SAFOR  development  is  work  of  high  quality;  (2)  the  suite  of  hardware  being 
used  in  non-optimal,  but  the  effort  to  change  it  is  not  currently  justified,  (3)  conversion  of 
the  software  to  anotltcr  lang„^gc  is  not  currently  jusrified,  (4)  the  objectives  of  the  SAFOR 
development  should  be  explicated  and  made  more  specific,  (5)  some  limited  measures 
should  be  taken  in  the  short  term  to  improve  the  adaptability  of  the  SAFOR,  but  more 
substantial  measures  should  be  pursued  in  a  longer  term  research  effort,  (6)  more  and  better 
tools  for  users  of  the  SAFOR  should  be  developed,  (7)  more  systematic  test  and  evaluation 
procedures  should  be  incorporated  in  the  SAFOR  effon. 
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INTRODUCTION  AND  SUMMARY 


On  26  June  1989  the  Defense  Advanced  Research  Projects  Agency  (DARPA) 
requested  that  the  Institute  for  Defense  Analyses  (IDA)  conduct  a  peer  review  of  the 
technical  approach  being  used  to  develop  the  Semi -Automated  Forces  (SAFOR)  for 
DARPA's  Advanced  Simulation  Technology  (AST)  Program.  This  review  was  held  on 
10-11  August  1989  at  the  Advanced  Simulation  Technology  Facility  in  Rosslyn,  Virginia. 

The  review  panel  consisted  of  the  following  members: 

Rodney  A.  Brooks 

Associate  Professor 

Massachusetts  Institute  of  Technology 

Bruce  G.  Buchanan 

Professor  of  Computer  Science,  Medicine,  and  Philosophy 

University  of  Pittsburgh 

Douglas  B.  Lenat 

Principal  Scientist,  Artificial  Intelligence  Project 

Microelectronics  and  Computer  Technology  Corporation 

David  M.  McKeown,  Jr. 

Research  Computer  Scientist 

Carnegie  Mellon  University 

Brief  biographical  sketches  for  the  panel  members  are  provided  in  Appendix  A. 

About  two  weeks  prior  to  the  review  meeting,  each  panel  member  received  a  "read- 
ahead"  package  that  provided  information  on  the  simulator  network  (SIMNET)  and  the 
development  of  the  SAFOR.  The  documents  included  in  this  package  are  listed  in 
Appendix  B. 

In  general,  the  panel  was  to  consider  the  following  question: 

Is  there  anything  in  the  development  of  the  SAFOR  that  should  be  done 

differently  to  better  meet  the  goals  of  the  SIMNET,  AST,  and  Advanced 

Battle  Simulation  programs? 

The  agenda  for  the  review  on  10-11  August  was  flexible,  but  it  included  four  basic 
activities: 


Orientation,  panel  responsibilities,  SEMNET  and  AST  objectives  and  technologies 
presented  by  LTC  Shiflett  and  program  staff. 

Description  and  discussion  of  SAPOR  objectives,  development,  and  technical 
approach  by  Bolt  Beranek  and  Newman  (BBN")  staff  (Duncan  Miller,  Stephen 
Downes-Martin,  and  Stephen  Deutsch).  The  briefing  materials  used  by  BBN 
for  this  portion  of  the  review  are  provided  in  Appendix  D. 

Discussion  and  review  of  SAPOR  technical  approach  by  the  panel. 

Debriefing  by  the  panel  for  DARPA  and  Army  representatives  on  the  SAPOR 
technical  approach. 

After  these  meetings,  members  of  the  panel  documented  their  impressions  of  the 
SAPOR  program  and  its  technical  approach.  A  brief  summary  of  their  comments  follows: 

1 .  Quality  of  the  work.  Three  of  the  four  panelists  commended  the  SAPOR 
development  as  high  quality  work,  done  by  good  people.  All  panel  members  concurred 
with  this  point  of  view  which  was  expressed  in  their  debriefing  on  1 1  August.  One 
panelist  mentioned  "edginess"  in  the  SAPOR  staff  --  a  concern  that  their  good  work 
completed  in  limited  time  with  limited  resources  would  be  rewarded  by  even  greater 
challenges  from  the  sponsor. 

2.  Hardware.  Three  of  the  four  panelists  stated  that  the  choice  of  hardware  for 
the  project  is  non-optimal.  How'ever,  all  three  also  recommended  against  any  ^'hange  to 
new  hardware  since  that  would  incur  high  costs  that  would  not  be  compensated  for  by  new 
capabilities  or  efficiencies.  They  also  suggested  that  changes  in  the  state  of  the  an  and  the 
scale  of  the  SAPOR  could  shift  the  balance  of  the  trade-off. 

All  four  noted  that  30-34  percent  of  the  Butterfly  computations  remains 
undetermined.  These  computations  will  impact  the  capacities  of  the  existing  system  to 
support  a  larger  scale  SAPOR.  The  panelists  suggested  that  these  computations  should  be 
better  understood  before  scaling  up  the  SAPOR  using  the  current  hardware. 

3.  Software.  Two  of  the  panelists  recommended  that  conversion  of  the  SAPOR 
software  to  Ada  be  strongly  resisted.  One  recommended  that  conversions  to  LISP  be 
similarly  resisted.  They  viewed  the  current  practice  of  programming  in  C  to  be  the  best 
compromise  choice. 
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4.  Objectives.  All  four  noted  uncertainty  in  the  objectives  for  the  SAFOR.  On 
one  hand,  there  is  some  value  in  this  un.-ertainty  since  it  allows  flexibility.  On  the  other 
hand,  design  decisions  require  definite  objectives.  The  impression  of  the  panel  appears  to 
be  that  the  balance  has  shifted  too  far  in  the  direction  of  uncertainty  and  that  more  explicit 
direction  is  needed  before  scaling  up  the  SAFOR.  Specifically,  more  certainty  is  needed 
concerning  (1)  whether  the  SAFOR  is  to  be  used  for  training,  equipment  capabilities 
testing,  or  doctrine  development,  and  (2)  if  training,  who  is  to  be  trained  to  do  what.  More 
certainty  will  help  determine  (1)  the  granularity  of  representation  needed  for  real  time  play 
and  after-action  review  and  analyses,  (2)  the  positions  that  must  be  kept  manned,  and 
(3)  the  hardware  and  software  architecture  of  the  SAFOR. 

Two  of  the  panelists  cautioned  that  attempts  to  scale  up  the  SAFOR  beyond  a 
currently  undefined  level  may  be  making  too  much  of  a  good  thing  —  it  may  extend  the 
technology  beyond  its  appropriate  application  limits. 

5.  Adaptability.  Three  of  the  panelists  discussed  "learning"  by  SAFOR  units  — 
the  ability  to  continually  adjust  tactics  in  the  iterative  manner  seen  in  fully  manned 
engagements.  The  panelists  suggested  that  more  could  and  should  be  done  to  enhance  this 
capability  in  the  short  term  through,  for  instance,  parameter  adjustments  and  incorporation 
of  the  route  planning  capabilities  emerging  from  other  R&D  projects.  However, 
adaptability  is  fundamentally  a  long-term  goal  deserving  support  as  a  research  project.  One 
long-term  approach  might  be  to  incorporate  more  real  world  knowledge  in  the  SAFOR. 

6.  Modifiability  and  Transfer.  Two  of  the  panelists  recommended  that  more  tools 
be  developed  to  increase  the  capabilities  of  users  to  modify  system  configuration  and  data 
structures.  One  panelist  stressed  the  need  for  better  system  documentation  to  better  support 
development  of  the  system,  improved  transfer  to  its  eventual  maintainers,  and  training  for 
new  users. 

7 .  Assessment.  Two  of  the  panelists  recommended  that  more  systematic  test  and 
evaluation  of  the  SAFOR  be  planned  and  provided.  The  scheduled  proof  of  principle  tests 
ai-e  helpful,  but  less  dramatic,  smaller  scale,  and  more  frequent  test  and  evaluation  should 
be  encouraged  and  supported. 

The  comments  of  the  panelists  in  their  own  words  are  clear  and  to  the  point.  They 
are  provided  in  Appendix  C  as  a  more  comprehensive  summary  of  panel  findings. 
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Recommendations  based  on  panelists'  comments  might  include  the  following: 

1 .  The  accomplishments  of  the  development  team  should  not  be  met  vtith  greater 
demands  and  fewer  resources.  A  mechanism  should  be  provided  for 
continuity  in  the  current  development  team. 

2.  An  analysis  of  the  hardware  requirements  for  the  SAPOR  should  be 
undertaken  assuming  several  scenarios  of  growth  and  scale. 

3.  The  objectives  for  the  SAPOR  should  be  clarified.  The  eventual  scale  -  or 
alternatives  for  the  scale  ~  of  the  SAPOR  should  be  clarified. 

4.  A  short-term  effort  should  be  made  to  improve  the  adaptability  of  the  SAPOR 
units.  A  long-term  research  effort  should  also  be  undertaken  to  improve  their 
adaptability. 

5.  Documentation  of  the  SAPOR  should  be  improved  and  better  tools  for  users 
should  be  developed. 

6.  Systematic  procedures  for  more  frequent  test  and  evaluation  should  be 
incorporated  into  the  SAPOR  development  program. 

7.  The  involvement  of  this  panel  in  the  SAPOR  development  should  be 
encouraged  and  continued. 

Other  recommendations  may  well  occur  to  readers  of  the  panelists'  comments. 
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APPENDIX  A 

BIOGRAPHICAL  SKETCHES  OF  PANEL  MEMBERS 


RODNEY  A.  BROOKS 

Rodney  Brooks  is  an  Associate  Professor,  Depanrrient  of  Electrical  Engineering 
and  Computer  Science  at  the  Massachusetts  Institute  of  Technology.  His  undergraduate 
training  was  in  mathematics.  He  received  the  Ph.D.  in  Computer  Science  from  Stanford 
University  in  1981.  He  has  held  research  positions  at  Carnegie  Mellon  University  and  MIT 
and  faculty  positions  at  Stanford  University  and  MIT.  His  current  research  is  in  the  MIT 
Artificial  Intelligence  Laboratory  where  he  works  on  completely  autonomous  mobile  robots 
with  particular  emphasis  on  vision  for  navigation  and  the  decomposition  of  control 
system.s. 

He  built  the  ACRONYM  vision  system  as  part  of  his  doctoral  work  at  Stanford. 
He  worked  on  the  definition  of  Common  LISP  and  its  first  supercomputer  implementation 
at  Lawrence  Livermore  Laboratories.  He  is  the  author  of  Model-Based  Computer  Vision 
and  Programming  in  Common  LISP  and  a  co-founding  editor  of  the  International  Journal 
of  Computer  Vision.  He  is  a  member  of  AAAI,  AAAS,  ACM,  and  IEEE. 

BRUCE  G.  BUCHANAN 

Bruce  Buchanan  is  a  Professor  of  Computer  Science,  Medicine,  and  Philosophy  at 
the  University  of  Pittsburgh  and  Co-Director  of  the  Center  for  Parallel.  Distributed,  and 
Intelligent  Systems.  He  received  the  B.A.  degree  in  mathematics  from  Ohio  Wesleyan 
University  and  the  M.S.  and  Ph.D.  degrees  in  philosophy  from  Michigan  State  University. 
Prior  to  joining  the  faculty  at  the  University  of  Pittsburgh,  he  was  a  Professor  of  Computer 
Science  Research  and  Co-Director  of  the  Knowledge  Systems  Laboratory  at  Stanford 
University.  His  research  interests  are  in  artificial  intelligence,  with  particular  emphasis  on 
intelligent  computer  programs  that  assist  .scientists  and  physicians,  including  programs  and 
methods  for  knowledge  acquisition  and  machine  learning,  scientific  hypothesis  formation, 
and  construction  of  expert  systems. 

He  is  a  Senior  Fellow  in  the  Center  for  the  Philosophy  of  Science  at  the  University 
of  Pittsburgh  and  a  member  of  the  Scientific  Advisory  Board  for  Oak  Ridge  National 


Laboratories  Energy  Division.  He  was  a  principal  in  the  design  of  the  DENDRAL,  Meta- 
DENDRAL,  MYCIN,  E-MYCIN,  and  PROTEAN  systems.  He  is  Secretary-Treasurer  of 
AAAI,  a  fellow  in  the  College  of  Medical  Informatics,  and  an  editor  of  Artificial 
Intelligence,  Machine  Learning  and  Knowledge  Acquisition. 

DOUGLAS  B.  LENAT 

Douglas  Lenat  is  the  Principal  Scientist  of  the  Microelectronics  and  Computer 
Technology  Corpoiation's  Artificial  Intelligence  Project.  He  received  the  Ph.D.  degree  in 
Comnuter  Science  from  Stanford  University  in  1976.  Prior  to  joining  MCC,  he  was  a 
professor  in  the  Computer  Science  Departments  of  Carnegie  Mellon  University  and 
Stanford  University.  He  is  also  a  founder  of  Teknowledge,  Inc.  His  research  interests 
concern  creative  discoveries  that  can  be  made  by  computer  programs  and  the  development 
of  common  sense  behavior  in  computer  programs  using  real  world  information  contained  in 
very  large  data  bases. 

In  addition  to  over  40  published  papers,  he  is  the  author  of  Knowledge  Based 
Systems  in  Artificial  Intelligence  and  Building  Expert  Systems.  His  thesis  work 
concerning  creative  discoveries  in  mathematics  that  could  be  produced  by  a  computer 
program  earned  him  the  IJCAI  Computers  and  Thought  award  in  1977.  In  1984,  he  was 
named  as  one  of  America's  100  brightest  scientists  under  the  age  of  40. 

DAVID  M.  MCKEOWN,  JR. 

David  McKeown  is  a  Research  Computer  Scientist  in  the  School  of  Computer 
Science  at  Carnegie  Mellon  University.  He  received  the  B.S.  degree  in  Physics  and  the 
M.S.  degree  in  Computer  Science  from  Union  College.  Prior  to  joining  the  faculty  at 
CMU,  he  was  a  researcher,  beginning  in  1975.  He  has  also  been  a  Research  Associate  at 
George  Washington  University,  a  Member  of  the  Technical  Staff  at  NASA  Goddard  Space 
Flight  Center,  and  an  instructor  at  Union  College.  His  research  interests  are  in  image 
understanding  for  aerial  photo-interpretation,  digital  mapping  and  image/map  data  base 
systems,  computer  graphics,  and  artificial  intelligence. 

He  has  been  the  principal  investigator  on  research  programs  sponsored  by  the  U.S. 
Army  Engineering  Topographic  Laboratories,  the  Defense  Mapping  Agency,  the  Air  Force 
Office  of  Scientific  Research,  and  the  Defense  Advanced  Research  Projects  Agency.  He  is 
a  member  of  AAAI,  ACM,  IEEE,  and  the  American  Society  for  Photogrammetry  and 
Remote  Sensing. 
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APPENDIX  B 

READ-AHEAD  DOCUMENTS 


Abrett,  G.,  Burstein,  M.,  Deutsch,  S.  TARL:  Tactical  Action  Representation  Language  - 
An  Environment  for  Building  Goal  Directed  Knowledge  Based  Simulations  (Report  No. 
7062)  Cambridge,  MA:  BBN  Systems  and  Technologies  Corporation,  5  June  1989. 

Ceranowicz,  A.,  Downes-Manin,  S.,  Saffi,  M.  SIMNET  Semi-Automated  Forces  Version 
3.0:  A  Functional  Description  (Report  No.  6939).  Cambridge,  MA:  BBN  Systems  and 
Technologies  Corporation,  6  March  1989. 

Ceranowicz,  A.,  Downes-Ma-tin,  S.,  Saffi,  M.  SIMNET  Semi-Automated  Forces  Version 
3.0:  Implementation  Issues  (Report  No.  6940,  Revised).  Cambridge,  MA:  BBN  Systems 
and  Technologies  Corporation,  27  October  1988. 

MacLaughlin,  D.M.  and  Shaked,  V.  Natural  Language  Text  Generation  in  Semi- 
Automated  Forces  (Report  No.  7092).  Cambridge,  MA:  BBN  Systems  and  Technologies 
Corporation,  5  July  1989. 

Meteer,  M.W.  The  SPOKESMAN  Natural  Language  Generation  System  (Repon  No. 
7090).  Cambridge,  MA:  BBN  Systems  and  Technologies  Corporation,  DRAFT  of  July 
1989. 

Orlansky,  J.  and  Thorpe,  J.  SIMNET  --  Engagement  Training  System  for  Tactical 
Warfare.  Journal  of  Defense  Research,  1989,  in  press. 

Pope,  A.R.,  Langevin,  T.,  Lovero,  L.,  and  Tosswill,  A.R.  The  SIMNET  Management 
Command,  and  Control  System  (Report  No.  6473,  Revised).  Cambridge,  MA:  BBN 
Systems  and  Technologies  Corporation,  July  1988. 

Semi-Automated  Forces:  Version  3jc  —  Design  Guidance  (Technical  Report  ITR-IOOI- 
6/89c).  Newbury  Park,  CA:  Illusion  Engineering  Incorporated,  COORDINATING 
DRAFT  of  19  July  1989. 

SIMNET  Command  Modules:  Simulation  for  Joint  and  Combined  Arms  Operations  at 
Echelons  above  Battalion  -  Data  Handbook  (Technical  Report  PTR-4106-07-1200-88-12). 
Chapters  1-4.  Woodland  Hills,  CA:  Perceptronics,  DRAFT  of  22  December  1988. 

Thorpe,  J.A.  The  New  Technology  of  Large  Scale  Simulator  Networking:  Implications  for 
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COMMENTS  ON  SIMNET/SAFOR  REVIEW 
AUGUST  10-11,  1989 


Rodney  A.  Brooks 
MIT  Artificiai  Intelligence  Lab 
Cambridge,  MA 

August  17,  1989 


1 .  The  Project 

The  overall  impression  of  the  SIMNET  project,  and  the  Semi-Automated  Forces 
(SAF)  project  in  particular,  was  very  good.  The  BBN  team  has  been  working  very  quickly 
to  produce  real  systems  and  has  made  great  progress  in  a  very  shon  time  frame,  apparently 
under  the  pressure  of  changing  goals. 

The  team  as  its  stands  is  very  innovative  and  creative.  Without  additional 
manpower  it  does  not  seem  appropriate  to  add  new  goals  to  their  already  busy  agenda. 
Also  it  does  not  seem  appropriate  to  task  the  current  team  with  conversion  to  Ada— such  a 
task  would  be  wasteful  of  their  talents  and  would  slow  the  whole  innovative  process  down 
significantly. 

2 .  Hardware 

A  particular  question  raised  concerned  short  term  hardware  acquisitions  to  scale  up 
the  size  of  the  SAF  that  could  be  operated  on  SIMNET. 

The  current  hardware  for  SAF  is  the  BBN  Butterfly  parallel  processor.  One  of  its 
cited  strengths  is  the  ability  to  add  more  processor  nodes  without  significantly  slowing 
down  the  shared  memory  access  time.  In  comparing  numbers,  however,  it  seems  that  a 
Butterfly  with  sixteen  68020  processors  could  rather  easily  be  beaten  by  a  MIPS  box  or  a 
SUN-4  uniprocessor,  without  any  overhead  for  shared  memory  between  processors.  A 
32-node  Butterfly  might  also  be  bested  by  such  a  processor  at  a  significantly  lower  cost. 

However,  there  would  be  a  significant  software  penalty  in  making  a  change,  and  it 
would  impact  very  badly  on  the  short-term  goals  of  the  project.  It  seems  prudent  to  stick 
with  the  Butterfly  for  now,  but  to  make  efforts  to  ensure  that  coding  standards  are  such  that 


the  SAF  code  will  be  completely  portable  eventually,  so  that  hardware  platforms  can  be 
seamlessly  replaced  to  take  advantage  of  the  increasing  processing  power  available  in 
modem  workstation  processors. 

3 .  Objectives 

There  seemed  to  be  some  confusion  over  the  goals  of  scaling  up  the  SAF  size,  no 
doubt  reflecting  different  constituencies  within  the  customer. 

One  argument  for  scaling  up  SAF  is  so  that  individual  crews  in  tank  simulators  can 
experience  some  of  the  large  scale  aspects  of  battle  that  are  not  generated  by,  say,  300  tank 
simulators.  Another  argument  calls  for  training  commanders  at  the  regiment,  division  and 
corps  level  by  giving  them  large-scale  exercises. 

In  the  first  case,  it  is  easy  to  see  problems  ahead  in  making  the  SAF  tanks 
indistinguishab'e  from  manned  simulators.  In  a  fight  to  win  situation  any  such 
distinguishability  will  be  seized  upon  by  the  human  participants  to  gain  advantage.  There 
are  some  short-term  improvements  possible  in  the  realsim  of  the  SAF,  mostly  by  adopting 
results  learned  from  the  DARPA  ALV  program  (e.g.,  the  Hughes  AI  Lab  work  on  cross¬ 
country  terrain  following).  However,  there  are  harder  issues  concerning  learning,  etc., 
which  seem  hard  to  address  in  the  long  term. 

In  the  second  case,  it  is  not  completely  clear  why  each  vehicle  needs  to  be  simulated 
as  an  individual  entity.  Large  performance  increases  may  be  gained  by  having  aggregations 
of  vehicles  which  are  only  there  when  you  look  at  them,  and  otherwise  are  hidden  in  the 
larger-scale  units,  which  are  simpler  to  simulate. 

It  is  worth  noting  that  for  significantly  less  than  $20B  it  would  be  possible  to 
replicate  the  current  hardware  to  provide  enough  simulators  that  the  whole  U.S.  Army 
could  be  involved  in  a  battle  simulation  simultaneously. 

4.  Scaling  Up 

In  terms  of  scaling  up  the  current  level  technology  SAFs  to  simply  have  more  of 
them,  it  seems  that  in  general  the  scaling  will  work  in  a  linear  or  sub-linear  fashion. 

Statistics  from  instrumented  simulations  on  the  Butterfly  were  presented.  Seventy 
percent  of  all  computation  was  well  accounted  for  and  it  seems  sure  that  all  of  that 
computation  will  scale  up  in  a  fashion  no  worse  than  linear  in  the  size  of  the  SAF. 
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Unfortunately,  thirty  percent  of  the  computation  was  unaccounted  for.  It  is  unclear 
where  this  computation  goes,  and  therefore  unclear  whether  it  scales  well.  It  may  be  that  it 
is  being  consumed  in  some  sort  of  message  conflict  resolution  at  the  network  level,  in 
which  case  it  may  not  scale  well.  It  is  important  to  monitor  this  component  of  the 
computation  carefully  in  initial  scaling  experiments  to  see  what  happens  to  it. 

5 .  Adaptability 

Currently,  all  aspects  of  the  system  are  rather  hidden  from  users  of  the  system, 
including  commander  planning,  doctrine,  equipment  descriptions  and  the  terrain  data  base. 
It  would  be  beneficial  if  end  users  could  have  mechanisms  to  modify  all  these  components 
without  having  to  go  out  to  govenrment  contracts  to  get  things  modified.  This  is  a  long¬ 
term  goal. 

However,  in  the  short  term  it  seems  that  the  SAP  commander  may  need  more 
flexibility  in  his  options  for  creating  plans  for  his  forces.  Currently  he  is  able  to  mix  and 
match  a  set  of  predefined  plans  (in  the  TARL/E  language)  and  feed  them  down  to  his 
SAFs.  Greater  realism  would  ensue  if  he  had  a  richer  interface  to  these  plans,  and  could  do 
the  sorts  of  operations  that  now  must  be  done  by  a  knowledge  engineering  programmer  in 
order  to  create  or  change  a  TARL/E  plan. 

6.  Learning 

SIMNET  has  demonstrated  how  manned  forces  adapt  and  learn  as  they  try  out 
weapon  systems  and  doctrine.  They  modify  their  behavior.  The  red  forces  also  modify 
their  behavior  and  there  is  a  continual  interplay  between  the  competences  of  the  two  forces 
as  they  gain  experience.  For  realism  of  the  SAFs  some  of  these  aspects  should  also  be 
simulated. 

To  some  extent  parameter  adjustments  in  the  SAF  over  time  can  improve  their 
performances.  However,  they  will  be  dumbfounded  by  innovative  tactics  developed  as 
experience  grows  among  the  human  participants.  This  could  lead  to  the  human  participants 
discerning  SAF  from  other  manned  simulators.  Rectifying  this  situation  is  not  a  practical 
short-term  goal,  but  rather  an  area  that  DARPA  could  fund  as  longer-term  research. 
Appropriate  RFPs  would  probably  lead  to  strong  responses  from  a  number  of  laboratories 
with  interests  in  these  areas. 


COMMENTS  ON  SIMNET/SAFOR  REVIEW 
AUGUST  10-11,  1989 


Bruce  G.  Buchanan 
University  of  Pittsburgh 
Pittsburgh,  Pennsylvania 


1 .  Overall  Impression 

Excellent  work  at  all  levels  from  problem  definition  and  management  to 
implementation.  The  actual  coding  is  an  impressive  tribute  to  what  a  small,  dedicated  team 
can  do  with  an  exciting  project. 

2 .  Hardware 

Because  the  technology  changes  rapidly  it  is  easy  to  suggest  alternative  hardware 
configurations  that  offer  improvements  over  yesterday’s  choices.  However,  the  cost  of 
changing  over  to  new  machines  in  the  next  year  are  sufficiently  high  that  the  current  rapid 
rate  of  development  would  be  slowed  unacceptably. 

3 .  Objectives 

There  are  many  implicit  objectives  driving  the  development  of  SIMNET  and 
SAPOR.  Both  training  of  personnel  and  evaluation  of  new  weapon  systems  are  worthwhile 
goals,  but  they  imply  different  priorities.  Even  within  either  of  these  two  major  goals, 
there  are  many  alternatives  for  directing  the  project.  For  example,  training  division 
commanders  implies  considerably  more  effort  on  artificial  intelligence  in  the  automated 
forces  than  does  training  platoon  commanders.  The  project  derives  some  of  its  vigor  from, 
lack  of  precise  objectives,  for  this  lets  the  staff  exploit  opportunities  as  they  arise  and 
exercise  considerable  ingenuity  in  doing  so.  On  the  other  hand,  transfer  to  the  Army 
implies  that  the  objectives  of  SIMNET  are  very  precise,  so  that  the  reimplementation  team 
can  make  the  proper  trade-offs,  for  example,  in  questions  of  human  engineering  (precisely 
who  are  the  intended  users?)  and  efficiency  (which  parts  of  the  code  will  be  exercised 
most?). 


4.  Scaling 

Answering  the  question  about  objectives  will  help  answer  the  question  of  which 
ways  to  scale  up  the  system.  Adding  more  units  implies  different  effort  from  adding  more 
battlefield  functions,  such  as  intelligence.  The  proposed  method  for  scaling  up  is  to  add 
more  computers  and  more  memory.  This  will  probably  work,  since  the  potential  problem 
of  exponential  growth  appears  to  be  avoidable.  System  overhead,  and  other  computing 
cycles  not  well  accounted  for  (about  30%  of  the  total)  need  to  be  examined,  however,  to  be 
certain  that  they  are  not  growing  exponentially. 

Another  method  for  scaling  up,  which  needs  to  be  examined  more  carefully,  is 
omitting  unnecessary  detail.  The  SIMNET  philosophy  is  to  include  all  details  in  order  to  be 
certain  that  fidelity  is  maintained.  Of  course,  even  SIMNET  omits  some  details,  such  as 
the  interactions  among  individual  crew  members,  battlefield  smoke,  civilian  behavior,  etc. 
So  it  is  recommended  that  this  issue  be  reconsidered  for  details  of  individual  vehicles  when 
operating  2-3  levels  (or  some  number  of  levels)  above  individual  vehicles.  Possibly,  too, 
the  psychological  fact  that  we  attend  to  about  seven  plus/minus  two  items  (whether  vehicles 
or  large  battle  units)  may  be  exploitable.  By  aggregating  and  expanding  (de-aggregating), 
the  current  SIMNET  computers  may  be  able  to  handle  two  orders  of  magnitude  scale-up 
with  acceptable  fidelity.  The  issue  is  not  as  clear  as  the  philosophical  axiom  of  including 
everything,  but  some  reconsideration  is  recommended  before  millions  of  dollars  are  spent 
on  scaling  up  by  adding  hardware  and  redesigning  software  to  cope  with  300,000  items. 

5.  Modifiability 

Once  the  program  is  out  of  the  hands  of  the  BBN  design  and  development  team,  it 
will  be  necessary  to  provide  better  tools  for  modifying  the  program  and  data  structures.  It 
must  be  clear,  also,  who  is  capable  and  who  will  be  allowed  to  make  changes.  The  system 
can  only  live  on  its  own,  however,  if  Army  personnel  (at  some  level)  can  reconfigure  units, 
add  or  modify  equipment  and  doctrine,  and  define  new  terrain. 

6.  Adaptive  Behavior 

Proposing  automatic  learning  in  any  units  opens  the  SIMNET  team  to  a  large 
research  area.  In  the  long  term  this  may  be  valuable,  for  example,  for  SAPOR 
commanders  to  improve  their  own  tactics.  There  are  too  many  other,  more  pressing 
problems  for  the  short  term,  however.  If  individual  SAPOR  vehicles  and  un:ts  adapt  to 
new  situations  more  readily  because  they  have  more  intelligence  and  more  autonomy,  there 


will  be  less  need  for  them  to  pause  and  request  instructions.  This  is  desirable  to  work  on  in 
the  short  term. 

7 .  Validation 

What  can  be  measured  to  convince  developers,  funders,  users  and  skeptics  that 
SIMNET  makes  a  positive  difference?  Again,  clarification  of  objectives  will  help.  It 
clearly  can  save  money  over  full-force  exercises  requiring  large  airlifts.  But  is  the  quality 
of  training  high  enough  to  accept  the  loss  of  fidelity?  Probably  so,  but  how  do  we  know  ? 

8.  Audit  Trail  and  Replay 

Much  more  can  be  done  with  replay  capabilities.  Part  of  the  design  philosophy  is 
that  personnel  will  learn  best  by  running  through  a  high-fidelity  simulation  without 
stopping.  This  is  imposed  on  SIMNET  by  the  fact  that  there  are  too  many  players  for 
back-up-and-replay  to  be  efficient.  When  there  is  a  single  commander  with  all  SAPOR 
units,  however,  the  situation  is  very  different.  Learning  does  increase  through  analyzing 
mistakes  and  working  through  them.  Pro  football  teams  have  used  films  and  drills  for 
decades,  for  example. 

Further  study  of  exploiting  SDMNET's  audit  trail  is  recommended. 


COMMENTS  ON  SIMNET/SAFOR  REVIEW 
AUGUST  10-11,  1989 


Douglas  B.  Lenat 
ArtiHcial  Intelligence  Project 
Microelectronics  and  Computer  Technology  Corporation 

Austin,  Texas 

My  overall  reaction  was  surprisingly  positive.  "Surprising"  because  1  believed  I 
was  cognizant  of  the  good  work  being  done  in  relevant  areas  of  AI,  simulation,  and 
DARPA-related  research;  yet  here  was  an  unfamiliar  project  right  in  the  intersection  of  all 
three  areas.  And  "positive"  in  the  sense  that  the  group  has  achieved  a  great  deal,  in  a  small 
period  of  time  and  given  very  limited  hardware  and  budgetary  resources. 

We  were  asked  for  our  comments  on  several  issues,  and  a  "consensus  opinion" 
was  delivered  verbally  at  the  end  of  the  day.  Below  is  my  personal  opinion;  1  have  marked 
with  an  asterisk  (*)  the  points  which  I  may  be  adding  to  the  consensus  opinion.  Unstarred 
points  are  ones  in  which  I  believe  the  rest  of  the  scientific  advisory  group  already  has 
discussed  the  issue  and  agrees  with  the  point  as  I  present  it. 

Issue:  What's  good  about  what  they've  accomplished? 

The  successful  blending  of  several  forefront  teohnologies  is  rarely  doable,  and 
never  painless.  In  this  case,  the  team  has  produced  a  seamless  integration  of  local  area 
networking,  long  haul  networking,  physical  simulators  and  displays,  and  on,  while 
maintaining  a  good  level  of  training  and  motivating  of  the  test  subjects,  motivating  of  the 
funders,  producing  milspec  documentation,  and  giving  briefings  such  as  this  meeting. 
Throughout  the  meeting,  I  was  consistently  impressed  with  the  people  who  spoke  (these 
were  mostly  the  BBN  researchers).  Their  level  of  intellect,  competence  at  their  task, 
motivation,  and  achievement  was  quite  astounding. 

Issue;  What's  bad,  or  a  "warning  sign",  in  the  project  at  present? 

(i)  One  obvious  weak  point  is  the  documentation.  Although  there  is  a  vast  stack  of 
it  (thousands  of  pages),  and  it  meets  milspecs,  it  is  quite  jargon-laden  and  almost 
impenetrable  to  anyone  not  already  familiar  with  the  project.  If  I  had  been  sent  this 
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dcKumentarion  before  agreeing  to  come  to  the  meeting,  I  would  have  declined  the  offer.  I 
am  therefore  glad  I  didn't  get  the  docs  until  just  before  stepping  on  the  airplane.  I  shall 
have  more  to  say  about  improving  this  situation,  below,  (ii)  A  second  "danger  sign"  is  the 
bitterness  that  was  evident  as  an  undercurrent  in  some  of  the  talks  and  remarks  we  heard. 
By  "bitterness"  I  mean  a  feeling  that  the  group  had  made  a  heroic  effort,  achieved  a  wild 
success,  and  yet  was  being  continually  pressured  and  harried  by  their  bosses  and  their 
funders  to  do  much  more,  and  more  quickly.  Their  edginess  over  this  is  a  warning  sign  of 
impending  burnout.  Given  their  experience  and  abilities  and  track  record,  I  hope  that  steps 
are  taken  to  relieve  this  pressure  somehow,  (iii)  A  third  warning  sign  was  the  military's 
assumption  that  "bigger  is  better"  (if  SIMNET  works  on  300  units,  let's  try  3000  or 
30,000)  almost  without  being  willing  to  question  whether  such  scaling  up  makes  sense. 
All  three  of  these  potential  problems  are  discussed  funher,  below. 

*  Issue:  How  would  you  suggest  ameliorating  the  documentation 

problems? 

The  documentation  problem  could  of  course  be  solved  in  the  usual  way  (hiring  a 
documenter),  but  I  recommend  a  more  knowledge-based,  on-line  approach.  Specifically,  I 
recommend  building  a  KB  (knowledge  base)  that  knows  about  the  system,  has  libraries  of 
cases  which  it  can  run,  etc.  This  program  can  be  used  in  three  separate  ways:  (a)  Via  a 
text  generation  program,  to  produce  a  document  of  the  system.  Depending  on  the  user 
model  —  military  spec,  novice  news  reponer  who  is  to  try  using  the  simulator,  AI  expen 
unfamiliar  with  the  project,  etc.  —  the  actual  document  generated  would  be  different.  (E.g., 
the  AI  expen  version  would  explain  the  military  acronyms;  the  milspec  version  would 
explain  the  AI  terms.)  (b)  Via  an  ICAI  program,  to  provide  on-line  training  for  a  new  user 
(or,  again  employing  user  models,  provide  on-iine  "training"  for  a  new  project  team 
member,  funder,  scientific  advisory  board  member,  etc.)  (c)  Have  a  mode  in  which  the 
large  case  library  is  quickly  "run  through,"  and  the  results  checked  with  what  the 
documentation  predicts  they  should  be.  This  is  a  way  of  automatically  detecting  bugs 
accidentally  introduced  into  the  system,  and  of  detecting  undocumented  changes  and 
updates  to  the  system  (which  would  make  the  documentation  incorrect.) 

*  Issue:  How  would  you  suggest  ameliorating  the  morale  problem? 

This  is  more  subtle,  but  I  would  reward  the  BBN  team  members  in  various  ways: 
(i)  allowing  and  encouraging  them  to  attend  relevant  conferences  (such  as  AAAI  or  IJCAI, 
and  the  annual  Machine  Learning  conference);  (ii)  allowing  and  encouraging  them  to  write 


up  some  of  their  work  for  publication  at  conferences,  in  journals,  and,  specifically,  in  the 
AI  Magazine;  (iii)  having  more  of  these  scientific  advisory  panel  meetings,  which  allow 
them  to  trade  ideas  and  receive  positive  feedback  from  their  colleagues;  (iv)  providing  more 
resources  and  relaxed,  rather  than  accelerated,  time  pressure,  Ada  pressure,  etc.  Although 
I  feel  strongly  about  this,  I  should  reiterate  that  this  is  still  only  at  the  "danger  sign"  stage, 
not  already  a  factor  hampering  the  project.  The  individual  researchers  are  still  putting  in 
long  hours,  are  enthusiastic  about  the  goals  of  their  project,  and  so  on. 

*  Issue:  What  is  "missing"  from  the  project? 

There  are  two  factors  which  might  be  missing  —  and  thereby  distorting  the  results  -- 
at  the  level  of  the  individual  soldier  sitting  in  a  simulated  tank.  These  two  factors  are  (a) 
terror,  or  at  least  very  serious  self-interest  that  that  soldier  should  feel  during  the  exercise, 
and  (b)  distractions  and  work  involved  in  communicating  with  the  various  other  crew 
members  in  that  same  tank.  Factor  (a)  could  be  dealt  with  by  having,  say,  real  money  at 
stake  over  the  outcome,  or  by  having  a  team  spirit  develop  as  with  athletic  competitions. 
We  have  heard  that,  unofficially,  of  course,  both  of  these  are  already  happening.  Factor 
(b)  is  completely  lacking,  though,  at  present,  and  it  would  be  relatively  easy  to  fix.  That  is, 
the  program  would  now  and  then  generate  messages  and  tasks  "from  his  crew"  which  the 
tank  commander  had  to  respond  to,  thereby  bleeding  away  some  of  his  attention  and  time. 
Talking  with  tank  crews  involved  in  combat  should  provide  the  necessary  heuristics  for  the 
types  of  messages,  the  frequency,  how  this  changes  under  fire,  how  it  changes  as  the  tank 
becomes  damaged,  and  so  on.  This  has  already  been  a  highly  recognized  factor  in  the 
verisimilitude  of  command  simulation  at  a  higher  level;  that  is,  the  company  commander  is 
not  getting  properly  trained  if  he  gets  to  sit  and  watch  the  progress  of  the  battle,  move  units 
around,  etc.,  and  needs  only  to  talk  to  his  superior  officer.  It  is  recognized  to  be  much 
more  realistic  to  have  much  of  his  time  taken  up  with  chatter  with  his  subordinate 
commanders.  I  am  just  suggesting  that  the  same  point  applies  at  the  level  of  the  individual 
tank,  not  just  at  higher  levels. 

Issue:  Is  the  current  choice  of  hardware,  software,  networking,  etc., 
adequate,  both  at  present  and  in  the  case  of  scaling  up? 

Our  answer  here  is  a  reluctant  Yes.  The  choices  were  reasonable  at  the  time  they 
were  made  (1983),  but  today  we  would  make  different  ones  (e.g.,  going  with  fast 
uniprocessors,  such  as  the  DEC-3100,  rather  than  the  slow  and  idiosyncratic  Butterfly 
machines.)  However,  the  vast  cost  to  change  now  (in  terms  of  lost  dollars,  months  of 
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time,  momentum,  familiarity,...)  is  not  worth  it.  When  and  if  the  system  is  re-engineered 
and  rebuilt  from  the  ground  up,  one  day,  then  it  would  be  appropriate  to  re-visit  this 
question  and  probably  take  a  different  path.  The  choice  of  the  C  language,  e.g.,  represents 
a  compromise  between  efficiency  (needed  for  realtime  simulation)  and  ease  of  development 
(easier  than  in  Ada,  harder  than  in  Lisp),  and  again  we  reluctaiuly  endorse  the  group's 
continued  use  of  it.  If  there  is  increased  pressure  from  the  military  for  them  to  convert 
SIMNET  to  Ada,  that  should  be  resisted;  in  the  end,  perhaps  the  SIMNET  nodes  can  be 
conceptually  packaged  and  sold  as  black  boxes,  with  very  specific  interfaces  which  can 
then  be  hooked  together  by  a  little  bit  of  Ada  code.  If  there  is  pressure  from  the  AI  research 
community  (such  as  myself)  to  convert  SIMNET  to  Lisp,  perhaps  that,  too,  should  be 
resisted,  at  least  until  it  can  be  shown  that  the  real-time  behavior  will  not  degrade. 

Issue:  Will  SIMNET  and  SAPOR  scale  up  to  larger  (3000)  and  larger 
(30,000)  forces  ? 

Most  of  the  algorithms  do  indeed  scale  up  linearly.  There  was  some  confusion 
about  34  percent  that  might  not;  we  are  not  claiming  anything  about  this  34  percent  -  we 
aren't  saying  it's  worse  than  linear  -  we  simply  weren't  told  (and  the  researchers  haven't 
yet  classitied)  what  that  34  percent  of  the  time  was  going  to.  This  needs  to  be  watched,  as 
the  scaling  proceeds.  However,  the  fact  that  humans  are  capable  of  doing  this  activity  in 
real  life  is  an  "existence  proof  that  linea*'  solutions  exist  to,  e.g.,  the  communication 
problem,  the  attention  problem,  and  so  on. 

Issue:  Should  this  be  scaled  up,  to  3000  or  30,000  units? 

This  is  a  different  issue,  and  one  we  were  not  explicitly  asked  to  consider. 
However,  there  seem  to  be  two  possible  purposes  of  the  entire  system,  and  they  each  --  to 
my  mind  --  suggest  a  No  answer  to  this  question,  (i)  The  purpose  is  to  train  better  tank 
commanders,  and  perhaps  company  commanders.  In  this  case,  there  is  little  to  be  gained  by 
scaling  up  at  all.  Fred  (who's  in  tank  42)  doesn't  really  care  what  is  happening  at  the 
division  level,  let  alone  some  other  division.  Look  at  it  this  way.  There  has  to  be  some 
level  below  which  it’s  not  cost  effective  to  simulate  (e.g.,  the  irrelevant  switches  in  the 
manned  simulators  are  just  painted  on;  the  head  and  arm  motions  of  the  individuals  in  the 
SAPOR  simulated  tanks  are  not  worth  simulating;  etc.)  And  there  has  to  be  some  level 
above  which  it's  not  cost  effective  to  simulate  (e.g.,  the  politics  and  economics  that  are 
happening  while  the  battle  is  going  on.)  It  is  possible  to  pick  an  incorrect  "lower  level"  - 
indeed,  this  was  my  point,  above,  about  needing  to  simulate  each  individual  in  the  tank. 
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even  though  only  the  tank  as  a  whole  is  visible  to  an  external  advisor.  And  it  is  possible  to 
pick  an  incorrect  "upper  level"  as  well,  (ii)  The  purpose  is  to  train  better  brigade,  division, 
regiment,  etc.,  commanders.  Here,  the  lure  is  that  by  having  actual  soldiers  in  the  simulated 
tanks,  there  will  be  useful  rich  detail  added  to  the  simulation  "from  below,"  for  these 
individuals.  But,  following  the  argument  we  just  made,  it's  hard  to  see  why  there  needs  to 
be  anything  more  than  a  simulation  running  two  or  three  levels  "below"  the  individual 
being  trained.  If  they  want  to  go  out  on  the  field  and  look  it  over,  the  simulator  ought  to  be 
able  to  provide  a  realistic  enough  view  of  what  might  be  happening.  So,  whether  you 
choose  purpose  (i)  or  (ii),  you  don't  need  a  massively  scaled  up  simulation  exercise.  Only 
if  you  want  the  same  system  to  simultaneously  do  both  tasks  do  you  need  the  scaling  up.  It 
is  important  to  realize  that  I  am  not  saying  "don't  invest  more  resources  into  this  project". 
It  is  a  marvelous  project,  as  I've  repeatedly  stated,  and  certainly  deserves  whatever  extra 
resources  can  be  found  for  it.  Rather,  it  is  a  question  of  how  best  to  use  those  resources, 
and  whether  just  blindly  scaling  up  is  the  right  way  to  go. 

*  Issue:  Should  the  project  expand  in  other  ways? 

A  direction  I  think  might  be  very  productive  would  be  to  make  the  simulator  more 
predictive,  more  proactive  rather  than  just  reactive.  In  other  words,  try  to  envision  what 
the  tank  commander  is  likely  to  do  next,  and  what  the  company  comm.ander  is  likely  to  do 
next,  etc.,  to  make  the  system  response  even  more  seamless  and  instantaneous,  to  make  the 
simulated  tanks'  behavior  (both  friendly  and  hostile)  more  realistic  (rather  than  having  them 
just  report  to  the  human  company  commander  that  some  unanticipated  situation  has  arisen, 
such  as  a  bridge  being  blocked  or  destroyed,  or...  well,  if  1  could  list  them  here  they 
wouldn't  be  unanticipated,  would  they?)  Very  low  levels  of  prediction  are  already  being 
taken  advantage  of  (the  places  this  tank  is  likely  to  go  in  the  next  instant).  Higher  levels 
would  require  two  additional  capabilities:  (i)  Scenario  generation  -  spinning  plausible 
chains  of  cause  and  effect,  and  planning  for  both  their  display  to  the  humans  in  the  loop, 
and  for  appropriate  reactions  of  simulated  vehicles  in  the  scenario.  Even  if  that  appropnate 
reaction  must  be  considered  and  decided  manually,  the  idea  is  that  it  can  be  done  before  the 
actual  SIMNET  battle  is  fought,  being  driven  by  machine-generated  scenarios  rather  than 
waiting  until  the  situation  arises  in  realtime  SIMNET  combat,  (ii)  Common  sense  -- 
including  both  having  a  vast  real  world  knowledge  base  of  facts,  heuristics, 
representations,  etc.,  about  objects  and  actions,  plus  having  a  large  repertoire  of  common 
sense  reasoning  methods.  This  gives  the  simulated  vehicles  a  chance  ot  coping  with 
unexpected  situations.  For  instance,  if  a  commander  decides  to  try  crossing  a  stream  by 
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driving  over  the  tops  of  half-sunk  recently-destroyed  tanks...;  or  if  a  pilot  tries  to  fly  under 
a  bridge...;  or  if  a  pilot  in  a  badly  damaged  plane  tries  to  crash  into  a  tank  or  -  even  more 
interestingly  -  a  fuel  depot;  or...  well,  you  get  the  idea.  Both  (i)  and  (ii)  are  immense  tasks 
in  their  own  right;  the  best  way  to  add  these  capabilities  might  be  via  collaboration.  One 
particular  pointer  relevant  to  Scenario  Generation  is  the  work  on  the  Strads  program  at  ESL 
tcontact:  A1  Clarkson,  408-738-2888).  One  particular  pointer  relevant  to  Common  Sense  is 
the  immense  KB  for  that  purpose  we  are  building  at  MCC,  namely  the  CYC  program. 

Parting  shot:  Let  me  conclude  by  remarking  that  this  is  only  the  second  project 
I've  seen  in  almost  two  decades  of  such  panel  meetings,  advising,  and  consulting,  where 
my  reaction  has  been  "I  want  to  get  more  actively  involved  in  this!"  Three  possible  roles  I 
see  for  myself  are  (a)  member  of  a  scientific  advisory  board  for  the  project,  which  meets 
periodically  to  review  progress  and  make  recommendations,  (b)  consultant  with  the  BBN 
researchers,  giving  more  direct  technical  feedback  and  suggestions,  and/or  (c)  collaborator, 
by  pursuing  the  proposal  (above)  to  have  SAPOR  cope  with  novelty  by  drawing  directly  on 
the  common  sense  in  CYC. 
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COMMENTS  ON  SIMNET/SAFOR  REVIEW 
AUGUST  10-11,  1989 


David  M.  McKeown,  Jr. 

Digital  Mapping  Laboratory 
School  of  Computer  Science 
Carnegie  Mellon  University 
Pittsburgh,  Pennsylvania  15213 

August  15,  1989 

The  working  group  was  convened  by  Dexter  Fletcher  of  IDA  on  August  10,  1989 
at  the  Rosslyn  SIMNET  Facility.  The  group  consisted  of  Rod  Brooks  (MIT),  Doug  Lenat 
(MCC),  Bruce  Buchanan  (PITT),  and  myself.  Lt.  Col  Jim  Shiflet  (U.S.  Army)  and  Col. 
Jack  Thorpe  (USAF)  gave  a  brief  introduction  to  the  SIMNET  program  and  described  the 
follow-on  effort  to  expand  the  scope  of  SIMNET  along  several  dimensions.  Of  particular 
interest  to  this  group  was  the  design  and  development  of  semi-  automated  forces  (SAFOR) 
that  could  be  used  to  simulate  friendly  or  opposing  forces  in  order  to  provide  the  ability  to 
simulate  larger  scale  engagements.  Given  the  cost  of  manned  simulators  it  was  felt  that  in 
order  to  accommodate  more  realistic  battle  scenarios,  including  aircraft  and  naval 
components  the  development  of  simulated  forces  was  the  only  way  to  provide  for  realistic 
engagements  at  the  battalion,  regiment,  or  corps  level.  Our  charter  was  to  listen  to  and 
evaluate  the  proposal/plan  to  develop  SAFOR  along  the  following  four  dimensions: 

1 .  Sizing  space 

2.  Response  time  requirements 

3 .  Flexibility  /  extensibility 

4.  Short  term  /  long  term  issues 

Since  we  have,  as  a  group,  already  summarized  our  findings  to  Dexter  Fletcher  and 
presented  them  to  the  SIMNET  'Committee  of  5'  I  will  restrict  my  comments  to  those  that 
might  refine  the  general  recommendations  and  observations  somewhat  outside  of  the  scope 
of  our  general  chaner. 
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Terrain  Issues 

At  several  points  in  the  discussion  statements  described  one  of  the  primary  goals  of 
SIMNET  to  allow  soldiers  to  train  in  an  environment  'modeled  on  real  world  terrain"  and 
'support  to  fight  anywhere'.  The  natural  implication  is  that  as  SIMNET  expands  beyond 
the  current  hand-generated  gaming  areas  the  requirements  to  have  a  highly  detailed  spatial 
data  bases  will  increase.  Further,  future  directions  such  as  radar  simulation,  modeling 
radio  communications,  etc.,  towards  an  ideal  Defense  Simulation  Internet  will  place 
increasing  importance  on  the  generation  and  maintenance  of  spatial  data.  It  is  likely  that  the 
SIMNET  program  will  have  to  directly  support  such  efforts,  or  be  a  strong  advocate  within 
the  Defense  Mapping  Agency  and  the  U.S.  Army  to  suppon  the  production  of  specialized 
data  on  which  the  simulations  are  based. 

The  terrain  level-of-detail  allowed  by  the  CIG  component  is  far  coarser  than  the 
level-of-detail  required  to  support  navigation  and  terrain  reasoning.  While  they  need  not 
(cannot)  be  the  same,  they  should  be  derived  from  the  same  underlying  data  base  so  as  to 
maintain  consistency  and  coherency  in  the  simulation. 

This  will  become  especially  true  as  the  SAFOR  development  continues.  Many 
problems  will  arise  if  the  SAFOR  can  plan  navigation  and  evasive  maneuvers  on  a  terrain 
model  that  either  can't  be  portrayed  or  can't  be  seen  by  the  manned  forces.  A  second 
problem  is  that  the  current  level  of  detail  may  smooth  out  many  significant  terrain  features 
that  are  key  to  manned  training.  For  example,  gullies,  ravines,  and  other  natural  terrain 
features  may  be  too  detailed  for  the  CIG  component  and  not  be  easily  modeled. 

Planning  Issues 

Plans  that  can  be  modified  during  an  exercise  appear  the  user  as  a  set  of  primitive 
building  blocks  that  can  be  linked  together  to  suit  the  particular  situation.  However,  it  was 
unclear  what  types  and  levels  of  exceptions  could  be  supported  using  TARL.  Does  this 
lead  to  stereotypical  behavior  by  SAFOR,  and  if  so,  how  does  this  impact  the  desire  to 
make  SAFOR  forces  indistinguishable  from  manned  units. 

Along  a  similar  line,  the  current  route  planning  techniques  are  clearly  inadequate. 
However,  even  if  the  current  state-of-thc-an  ALV  routing  algorithms  were  employed  it  is 
not  clear  whether  these  capture  the  types  of  constraints  used  in  terrain  masking  during 
cross-country  movement.  Some  effort  ought  to  be  placed  in  understanding  the  tactics  of 
cross  country  movement,  as  opposed  to  simple  point-to-point  navigation  with  obstacle 
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avoidance.  For  example,  there  is  a  natural  tension  between  maintaining  formations  and 
local  planning. 

There  seems  to  be  an  asymmetry  between  the  level  of  replanning  performed  by 
manned  units  and  the  level  described  for  SAFOR.  How  important  is  dynamic  plan 
adjustment? 

System  Integration  and  Evaluation 

I  have  the  impression  that  more  isolated  testing  of  the  SAFOR  forces  is  needed  in 
order  to  insure  that  their  behavior  can  be  incrementally  evaluated  and  improved.  I  do  not 
have  a  good  impression  that  the  BBN  team  has  a  plan  for  test  and  evaluation  before 
unleashing  SAFOR  on  users.  In  my  opinion  some  significant  effon  will  be  required  to  get 
the  SAFOR  subsystem  to  a  useful  level  of  play.  Evaluation  ought  to  determine  whether 
humans  can  distinguish  between  manned  and  SAFOR  vehicles. 

What  is  the  test  plan  for  SAFOR?  What  constitutes  an  acceptable  level  of 
performance?  What  is  an  appropriate  ratio  of  manned  to  unmanned  units? 

As  was  discussed  in  the  summary  meeting,  the  timings  presented  do  not  adequately 
allow  us  to  make  a  judgement  as  to  whether  the  current  architecture  can  support  one  or  two 
orders  of  magnitude  more  simulated  vehicles.  As  a  part  of  the  performance  analysis 
portion  of  the  follow-on  contract,  some  effort  should  be  expended  on  a  much  more  detailed 
measurement  of  the  system  load  and  overheads  (largely  unreponed  on)  and  whether  the 
Butterfly  architecture  can  support  extensions  without  samration  of  the  memory  interconnect 
network.  Again,  there  seems  to  be  a  lack  of  understanding  of  the  dynamics  of  the 
simulation. 

In  addition  to  the  previous  point,  that  calls  for  better  measurements  of  the  current 
state  of  the  simulation,  there  is  a  significant  possibility  that  increased  reasoning  about  the 
terrain  and  in  executing  plan  exceptions  could  greatly  change  the  timing  mix  of  the  tasks 
that  must  be  performed  by  the  SAFOR.  The  current  path  planning  is  the  most  simplistic 
technique  that  still  encompasses  search.  However,  the  global  optimization  of  A*  is  not 
likely  to  be  representarive  of  the  computational  load  required  for  adaptive  search  including 
terrain  and  mission  constraints. 
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General  Issues 

There  appears  to  be  an  obvious  tension  within  SIMNET  in  deciding  what  role 
future  evolution  of  the  program  should  take.  The  fundamental  question  is  who/what  is 
SIMNET  trying  to  affect/train/impact?  There  does  not  appear  to  be  a  clear  consensus  on 
this  issue.  One  view  might  be  that  SIMNET  has  shown  effectiveness  as  a  training  aid  at 
the  battalion  and  company  level  and  should  therefore  be  extended  to  the  regiment  and 
divisional  support  Another  view  is  that  there  are  many  holes  in  the  current  level  of  realism 
at  the  battalion  and  company  level  and  these  should  be  addressed  before  trying  to  scale  up 
to  larger  scenarios. 

The  stated  goals  of  getting  SAPOR  to  a  point  of  sophistication  where  an  entire 
regiment  or  battalion  could  be  simulated  by  one  person  is  clearly  driven  by  the  desire  to 
perform  larger  scale  simulations  as  efficiently  as  possible.  It  is  unclear  whether  the  state- 
of-the-art  in  terrain  reasoning,  utilization  and  operationalization  of  tactics  and  doctrine,  and 
in  real-time  analysis  of  multi-purpose  agents  will  support  such  a  goal.  Driving  the 
SIMNET  project  in  this  direction  prematurely  will  probably  result  in  a  failure.  It  is  not 
clear  to  me  that  even  in  the  long  term  (5-10  years)  full  simulations  as  envisioned  in  the 
Defense  Simulation  Internet  would  be  practical  at  a  level  of  realism  that  would  be  acceptable 
as  fulfilling  a  training  goal.  Backing  off  from  the  concept  of  a  highly  independent  SAPOR 
acting  with  intelligence  and  cunning  can  be  achieved  by  keeping  more  men  in  the  loop. 
While  this  might  appear  less  cost  effective,  it  probably  keeps  SIMNET  on  a  more 
traditional  development  path,  rather  than  straying  into  basic  research. 
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SAFOR  BRIEFING  MATERIALS 
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Semi-Automated  Forces 


Concepts  and  Approach 


Stephen  Downes-Martin 
BBN  Systems  and  Technologies  Corp 
10  Moulton  Street 
Cambridge,  MA  02138 


Problem  Domain 
Problem  Statement 
Technical  Requirements 

Scope  the  Problem 

Expand  the  Goals 
Underlying  Concepts 


Advanced  Simulation  Division 


Problem  Domain 


•  Tactical  Combined  Arms  Combat 

•  An  adversarial  high  risk  high  intensity  real  time  activity  in 
in  uncertain  and  lethal  environment  which  integrates  the 
maximum  use  ofvioience  with  the  maximum  use  of  Intellect. 


•  Agents  (many  variants  of  each) 

•  Vehicles 

•  Weapons  (vehicle  mounted) 

•  Units 


In  a  Soviet  Regiment 
600,  50  types 

10  types 

12  functional  types 


•  Activities 

•  Planning,  execution,  monitoring,  diagnosis,  prediction. 

•  Battlefield  Functional  Areas  (BFA) 

•  Maneuver,  Fire  Support,  Air  Defense,  lEW,  C3I,  MCM, 
CAS  and  BAI,  CSS. 

•  Cognitive  and  physical. 

•  Complex  and  interactive. 


•  Complex  domain  exhibiting  breadth  and  depth 

•  Each  command  level  introduces  new  concepts,  agents, 
and  tasks:  the  whole  is  greater  than  the  sum  of  Its  parts. 

•  Non  linear  growth  in  complexity  with  command  level. 
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Problem  Statement 


•  Provide  a  Command  Post  Interface  to  SIMNET  so  that  a  TOC 

commander  and  staff  can  command  and  control  large  forces 
(flank,  supporting,  enemy),  without  the  requirement  of  manned 
simulators,  which  interact  on  the  SIMNET  battlefield.  This  will 
be  achieved  by  the  use  of  sofware  driven  semi-automated  forces 
(SAP). 


•  Use  SAP  within  the  SIMNET  arena  to  support 

•  Joint  and  combined  arms  training. 

•  Combat  developments. 

•  Large  scale  high  resolution  combat  simuiation. 

•  Integration  of  command,  team,  and  crew  training. 


V 
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Design  Guidance 


•  SAF  is  a  manned  simuiation.  Humans  are  in  command. 
SAF  is  manned  by  commander  and  staff  of  the  highest 
echeion  represented.  Humans  fight  to  win. 


•  SAF  machine  inteliigence  executes  human  command  guidance 

in  accordance  with  doctrine  and  with  sufficient  operational  | 
realism  that  battlefield  tactics  are  not  affected. 

A  weak  form  of  the  Turing  Test. 

•  Critical  tactical  decisions  are  reserved  for  the  human  commander. 
SAF  system  provides  advance  warning. 

•  Human  commander  and  SAF  interact  via  formatted  military 
messages  (OPORDs,  FRAGOs,  Requests,  Reports).  They  carry 
out  their  warfighting  tasks  in  a  manner  as  close  as  possible 
the  real  world. 

•  Human  comander  can  relocate  focus  of  awareness  and  control 
to  any  software  subordinate. 

•  The  SAF  must  work  —  goal  driven  R&D 

•  Demos  are  hands  on  warfighting  excercises  by  soldiers. 

•  Demos  are  a  subset  of  broad  but  focussed  R&D. 

•  Deliverables  are  a  robust  subset  of  demo  functionality. 
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Technical  Requirements 


SAP  interacts  with  SIMNET.  Humans  in  manned  simulators 
can  eyeball  the  SAP  BOS 

•  Maintain  physical  integrity  of  SAP  BOS. 

•  SAP  BOS  operate  at  similar  response  rate  to  manned 
simulators. 

•  SAP  BOS  operate  at  similar  levels  of  realism  to  manned 
simulators. 

•  Must  simulate  BOS  crew  performance  as  well  as 
BOS  equipment  performance. 

•  SAP  BOS  and  manned  simulators  share  some 
computational  requirements  on  external  performance. 
Minimum  computational  requirement  exists  driven 

by  realistic  appearance  requirement. 

SAP  interacts  with  human  TOC.  Humans  in  TOC  can 
command  and  control  subordinate  SAP  units. 

•  Must  simulate  communications  flow  between 
human  TOC  and  subordinate  SAP  units. 

•  Must  provide  decision  support  software  for  TOC. 

SAP  BOS  are  software  driven 

•  Must  simulate  warfighting  tasks  of  subordinate  SAP  units. 
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Conflicts  Between  Requirements 


Problem  Scoping 


Bound  the  problem  breadth 

•  Identify  critical  tasks  and  activities. 

Bound  the  problem  depth 

•  identify  what  is  good  enough  for  tactical  reality. 

•  Use  domain  knowledge,  two  thousand  years  of  documented 
expertise. 

Avoid  research  black  holes  —  performance  directed 

•  Human  commander  carries  out  hard  cognitive  tasks. 

•  Generate  fully-manned  appearance  by  gestalt  approach 

•  Human  can  insert  himself  into  any  decision  node. 

•  Human  in  supervisory  control  of  software. 

•  Avoid  re-inventing  the  wheel 

•  Judicious  integration  of  many  techniques. 

Advanced  Simulation  Division  |  ^ 
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Original  Goais 


•  Spring  1986  -  Originai  proposai  accepted  by  DARPA 

•  OPFOR  Armor  oniy. 

•  Fire  and  Maneuver  oniy. 

•  Piatoon  ievei  workstations  controi  SAF  piatoon  vehicles. 

•  Company  workstation  communicates  with  platoon  workstations. 

•  Concentration  on  autonomous  and  cooperative  behavior  at  the 
piatoon  level  to  establish  techniques  for  future  expansion  . 


•  Milestones 

•  Simulation  of  tele-operated  vehicle. 

•  Autonomous  vehicle. 

•  Cooperative  behavior  between  vehicles. 

•  Platoon  commander's  workstation. 

•  Cooperative  behavior  between  platoons. 

•  Five  full  time  equivalents,  thirty  months  duration. 

Advancod  Simulation  Division  I  e  I  i  1  b  I 
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Goals  Expanded  as  Project  Develops 


•  Mar  1986:  Original  proposal  accepted,  delivery  Fall  1988. 

•  Nov  1986:  Future  expandability  becomes  a  goal 

•  Focus  efforts  away  from  Intelligent  behavior  and  onto  SMI. 

•  Include  automatic  explanation. 

•  Avoid  risky  Al  research. 

•  Expand  from  platoon  to  regimental  workstation. 

•  Include  artillery. 

•  Two  order  increase  in  vehicle  numbers.  Begin  parallel  effort  into 
Butterfly  implementation.  Butterfly  chosen  as  most  cost  effective 
in  1986  with  Incremental  expansion  capability. 


•  Jan  1987:  Goals  expanded 

•  Include  helicopter  and  fixed  wing  aircraft. 


•  Field  system  by  Aug  1987. 


Mar  1987:  Goals  expanded 

•  Workstation  requirement  reduced  from  regimental  to  battalion 

•  include  logistics. 

May  1987  Demo 

•  Version  1.0  at  Armor  Conference  Ft  Knox. 

Masscomp  based,  ground,  red,  company  workstations. 


Dec  1987:  Goals  expanded 

•  Include  US  units  and  tactics. 

Mar  1988  Demo 

•  Version  2.0  at  FAADS  Test  Ft  Knox. 
•¥  Butterfly  based,  air,  blue. 

Mar  1989  Demo 


Version  3.0  distributed  SAF  PoP  demo. 


•f  integrate  ground  and  air,  battalion  workstations. 


Advanced  Simulation  Division 
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Vertical  Scaling 

The  Advanced  r  'ttle  Simulation  (ABS) 

•  Current  System 

•  OPFOR  Regiment  (-)  vs  BLUFOR  Battalion  (-) 

•  300  vehicles 

•  Expansion  in  Two  Phases,  each  phase  exhibits 

•  10  times  Vehicles  (3000  and  30000) 

•  5  times  Units 

•  10  times  increase  In  cognitive  complexity 

•  100  times  increase  in  interactions 

•  Two  major  classes  of  scaling  Issues. 

•  Number  of  simulation  objects,  combinatorics  of  Interaction. 

•  System  becomes  dominated  by  cognitive  factors  at  high 
command  levels. 

Advanced  Simulation  Division 
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DEFENSE  SIMULATION  INTERNET 
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ATTRIBUTES  OF  THE  BCIP  SIMNET  BASED  BATTLEFIELD 
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•  EACH  SIMULATED  FUNCTION/SYSTEM  HAS  REAL  WORLD  ATTRIBUTES 

•  MAN-IN-THE-LOOP  AT  EVERY  VITAL  DECISION  POINT 

•  INTEGRATED  BATTLERELD-INDIVIDUAL  MANNED  SYSTEMS  A  WORKSTATION  CONTROL  INTERCHANGEABLE 

•  THESE  DIFFERENCES  MEAN  THAT  OPPOSING  COMMANDERS  "SEE”  THE  BATTLE  AS  IN  ACTUAL  COMBAT 


BN  WORKSTATION 
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Typical  Sequence 


1. 


2. 


3. 


4. 


5. 


6. 


7. 


Conduct  battlefield  reconnaissance  in  simulator. 

Receive  operation  order. 

Input  operation  order  to  SAP  workstation. 

Position  seif  in  TOC  or  simulator. 

Receive  contact  report  (from  workstation  or  manned  simulator). 

Report  to  regiment  or  brigade  (voice,  paper). 

Obtain  combat  support  or  combat  service  support 
(automated  via  workstation  or  via  comms  to  other  warfighters). 


Si 


Advanced  Simulation  Division 
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Soldier  Machine  Simulation 
Spectrum 


•  SAF  simulates  vehicles,  weapons,  crews,  staffs. 

Machine 

simulation 

A 

•  SAF  vehicies  and  weapons  have  same  external  performance 
and  appearance  as  manned  simulators. 

•  SAF  vehicles  and  weapons  have  simplified  internal  damage 
models  (catastrophic,  mobility,  firepower,  and  comms  kills) 
compared  to  manned  simulators. 

•  Simulated  SAF  vehicle  crew  members  reactiveiy  and 
proactively  apply  battle  drills  and  combat  SOPs. 

•  Simulated  SAF  command  staffs  reactiveiy  and  proactively 
apply  command  and  leadership  functions,  subject  to 
supervisory  control  by  human  commanders. 

•  Human  commanders  fight  to  win  and 
supervise/C2  software  subordinates. 

T 

Man 
in  the 
Loop 


V 
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Gestalt  System 
The  Human  Component 


•  The  SAP  human  commander 

•  is  in  supervisory  control  of  automated  subordinate 
staffs  and  weapon  systems  in  a  real  time  situation. 

•  can  control  downwards  when  subordinate  software 
is  unable  to  maintain  tactical  realism. 

•  must  fight  to  win. 

•  cannot  subvert  battiefieid  physics. 

•  controls  assets  via  a  simulation  of  C3I. 

•  reports  upwards  to  a  fully  manned  TOC. 


Advanced  Simulation  Division 
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The  Gestalt  System 
The  Automated  Component 


•  Automated  control  achieved  using  mind/body  paradigm. 

•  Mind  is  the  Tactical  Action  Representation  Language  used 
for  building  missions. 

•  TARL  is  a  hierarchical  contingent  procedural  language. 

•  TARL  constructs  are  executable  mission  descriptions 
(plan  repre;>aniations)  for  agents  of  the  simulation. 

•  Contingency  construct  permits  arbitrary  level  of  detail 
to  be  built  on  the  fly  when  responding  to  environment. 

•  Editor  provides  interface  to  graphical  representation 
of  mission  descriptions. 

•  Body  is  a  set  of  SOPs  coded  at  each  simulation  agent. 


Advanced  Simulation  Division 
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White  Box  Approach 


•  Three  levels  of  SAF  simulation 

•  vehicle  and  weapons  systems  parameters. 

•  vehicle  and  unit  behavlor/tactics  parameters. 

•  human  commander  generated  missions. 

•  Each  has  a  text/graphical  editor 

•  Models  editor:  used  by  Battle  Master. 

•  Tactical  action  editor:  used  by  the  developer 

(user  or  contractor). 

•  Commanders  interface:  used  by  the  human  commander. 

•  Editors  create  a  white  box  system 

•  examine  parameters. 

•  modify  parameters. 

•  user  becomes  responsible  for  the  underlying  parameters. 

Advanced  Simulation  Division  j  ^  mm 
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SAF  3.x  OBJECTIVE 

Transform  System  Demostrated  in  March 
(SAF  3.0)  into  Reliable  System  for  Transi¬ 
tion  to  Army. 

SAF  3.x  Will  Support: 

•  Troop  Training 

•  Combat  Development  Experiments 
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Long  Haul  Network  Archtitecture 


D-2  3 


OPFOR  at  BBN  Cambridge 


Regt  Cmd  Grp 


Phone  Line _ 

Voice  Comma  to  Ft  Rucker  and  Ft  Knox 


-Tk  Bn 


-Tk  Bn 
-Mr  Bn 


Fixed 

-Wing 


Rotary/ 
Wing 


— Artillery 


CSS 


Tactical  Comma 


2  M1a 


CD~ 

C3i 


x 


SAF  Butterfly 


X 


SAF  Butterfly 


X 


SAF  Butterfly 
SAF  LAN 


Glh 


CP 


SIMNET 

MCC 


X 


Long  H 
Gateway 
Butterfly 


aul 


Stealth 


Plan  View 
Diaplay 


iDataiogger 


SIMNET  LAN 


Legend 

(_) 

Workatation 

Manned  Simulator 
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ENHANCEMENTS 

•  Increase  Numbers  of  Vehicles 

•  More  Intuitive  Interface  for  Soldiers 

•  Fair  Play 

•  Increase  Vehicle  Intelligence 

-  Standard  Operating  Procedures 
-Tenain  Reasoning 

•  Ability  to  Task  Organize 

•  Store  and  Retrieve  Scenarios 

•  Dismounted  Infantry 

•  Mixed  Manned  and  Automated  Units 

•  Reliable  and  Robust 

•  No  Proprietary  Code 
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Simntt  Stml-AutomaU<i  Foretx  ExptrUntntal  Worknatlon 
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WORKSTATION  SINIHOST  COMMUfJlCATATIONS 


SAF 

COMMANDER 

WORKSTATION 

SAF 

SAFLAN 

SIMHOST 

SIMSTT 

C^  MAP 

L_p-pJ  * 

CONTROL  MESSAGES: 
CONN'ECT 
DISCONNECT 


TIME 


INirn’ASK  ORGANIZATION: 
CREATE 

RESET  - 

ATTACH  - 

DETACH  - 


CREATION 

RESET 


INFORMATION: 

REQUESTS 

POLLS 


REPORTS 
POSITIONS 
STATUS 
RRE  INFO 


UMT/VEHICLE  COMMAND  MESSAGES: 

START.ACnvrTY  - - 

ABORT.ACnVTTY  - 

SUSPEND.ACnVTTY  - 

RESUME.ACnVITY  - 


ACTIVITY  COMPLETE 
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WORKSTATION  ARCHITECTURE 


COMMAND  NET  &  SIMULATION  HOST 
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.S'linnet  Sfmi-Aulomattd  Forcn  h'»ptnmrnlnl  Workilalion 
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Jan  kayUim  4  LL  U*  : 


WORKSTATION  COMMANDS 


System  Commands 

-Connect/Diconnect  From  Simhost 

-  US  Units/Russian  Units 

-  Select  Team 

-  Create/Clear  Units 

Map  Commands 

-  Zoom,  Pan,  Rescale,  Refresh 

-  Show,/Hide:  Roads,  Water,  Trees,  Contours,  Grid 

-  Overlays:  Draw,  Save,  Restore  and  Edit 

Unit  Commands 

-Fire  Control:  Skill,  Range.  Fire  Permission 

-  Regroup 

-  Face  Direction 

-Assign,  Show,  Suspend,  Resume,  Abort 
Mission 


ASSIGNING  A  MISSION 


•  Select  A  Mission  From  Menu 

-  March 

-  Attack 

-  Defend 

-  Delay 

-  Resupply 

-  Withdraw 

•  Prompts  for  Parameters 

-  Routes  and  Roads 

-  Control  Measures  from  Overlays 

-  Speeds  ... 

•  Select  Time  to  Start  or  Store  as  Contingency 
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A  MORE  SOLDIER  FRIENDLY  INTERFACE 


Use  Command  Representations  Familiar  to  Sol¬ 
diers 

-  Unit  Symbols  in  Task  Organization 

-  Use  OPORD  Format  to  Access  Operations 

-  Extend  Use  of  Control  Measures 
~  Provide  More  Overlays 

Separate  Command,  Initialization,  and  System  Func¬ 
tions 

Provide  More  Feedback  and  Status  Information 


SIMNRT  Scmi-Aiiuimaicd  Forces  WorksUlion  (Vcreion 


ROUTE  PLANNING 

•  Subordinate  Unit  Routes 

-  Battalion  Boundaries  to  Company  Routes 

-  Translate  Company  Routes  to  Platoon  Routes 

-  Check  for  Routes  Crossing  Water 

•  Route  Planner  on  Road  Networks 


SIMULATION  HOST  ARCHITECTURE 
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UNIT  FUNCTIONS 


•  Represent  Unit  Structure 

-  Promotion 

-  Task  Organization 

•  Distribute  Orders 

-  Tasks  and  Missions 

-  Fire  Parameters 

-  Requests 

•  Send  Back  Reports 

-  Filter 

-  Aggregation 

•  Coordinate  Subunits 

-  Fire  Zones 

k  -  Movement 
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UNIT  SIMULATION 


EVENT 

LIST 


VEHICLE 
TABLE  ♦ 


COMMANDS  ANT)  ACTIVITIES 


UNIT 


COMMANT)S  TAKE  THE  FORM  OF 
START  ACrrVITY  (NAME.  ARGl. ...) 


INTERPRETTED 

ACTIVITIES 

PROVIDE  CONTROL 
BY  SPAWM.NG  AND 
TER.MIN.ATING  CHILD 
ACTIVITIES 

T'lTHS 

SEQUENTIAL 
PAR.ALLEL 
PARALLEL  STOP 
CYCLIC 
CONDITIONAL 
DO  LIST 


BASIC 

ACTIVITIES 

PROVIDE  STATE 
CHANGE  BV  EXECUTING 
C-FLAVORS  METHODS 

INCOMPATABLE 
ACnVITIES 
SUSPENT>ED  OR 
ABORTED  BY  CLASS 


(derinc_actjvity  keep_staiion  () 
((class .  maneuvfr)) 

(cycle 

(update_station) 
(paraJlcLstop 
(wait  5000) 
(inovc_lo_point)))) 


VEHICLE  FUNCTIONS 

•  Look 

-  Intervisibilty 

-  Detection  and  Identification 

•  Move 

-  Go  to  Point 

-  Avoid  Obstacles  and  Collisions 

•  Shoot 

-  Target  and  Weapon  Selection 

-  Load,  Track,  and  Fire 

•  Communicate 

-  Receive  Commands  and  Requests 
“  Trigger  and  Send  Reports 

•  Logistics 

•  Damage 
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VEHICLE  SIMULATION 


r 


I 


I 


I 


I 


I 


I 
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SINENTT  QUEUE 


TO  SIMNET 


COMMS  QUEUE 


TO  UNIT 


VEHICLE  DYNAMICS 

•  Ground  Vehicles 

-  8  Decrees  of  Freedom 

w 

Turret  Azimuth  and  Gun  Elevation 

-  Integrate  Azimuth,  X,  Y,  Z 

-  Limit  Acceleration,  Speed,  and  Turn- 
rate  by  Vehicle  and  Soil  Type 

-  Fit  Pitch  and  Roll  to  Match  Soil 

-  Collision  Checks 

•  Air  Vehicles 

-  6  Degrees  of  Freedom 

-  Nap  Of  the  Earth  Look  Ahead 
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VEHICLE  AND  UNIT  MOVEMENT 


•  Vehicles 

-  Move  to  Point 

-  Keep  Station 

-  Obstacle  and  Collision  Avoidance 

•  Platoons 

-  Follow  route 

*  Issue  Waypoints  to  Leader 

*  Wings  Keep  Station  on  Leader 

-  Follow  Road 

*  Issue  Waypoints  to  All  Vehicles 

•  Companies 

-  Issue  Routes  and  Roads  to  Platoons 

•  Time  Based  Coordination 

•  Bridge  Crossing 

•  Promotion 


RADIO  COMMUNICATIONS 


Performance  Problems: 


MOVE:  Coilision  &.  Obstacle  Avoidance, 

•  Potential  collisions  with  obstacles,  and  all  other  vehicles. 

•  OiN^)  problem. 

SHOOT:  Target  Acquisition. 

•  All  other  vehicles  are  potential  targets. 

•  Visibility  is  a  function  of  terrain. 

•  Manned  simulators  have  special  hardware  (Z-buffer)  which  determines 
intervisibility  as  a  by-product  of  display. 

•  The  human  soldier  acquires  targets  from  visible  vehicles. 

•  SAF  Simhosf  has  no  special  h/w.  It  must  perform  polygon  intersections 
to  determine  intervisibility. 

•  SAF  Simhost  uses  a  detection  model  (arcs  of  attention)  to  acquire  targets. 

•  0(N')  problem. 

CO.MMLMC.ATE:  Inter-vehicle,  inter-machine  communications. 

•  Workstation  Simhost  Communications. 

•  Simhost  <=>  SIMNET  Communications. 

•  Unit  <=>  Unit  Communications. 

•  0{N)  problem. 
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Processing  Requirements 

All  #s  as  percent  of  time  during  whole  run 

MOVE: 

16.4 


11.2 

9.2 


7.8 


I/O; 

7.4 

SHOOT: 

6.3  intervis 

6.3  point-to-point  computation 

1.3  choosing  vehicles  to  test 

0.7  detection  database  lookup 

0.8  detection  computation 

6.1  targeting 

2 . 9  maintain  target  list 

1.7  moving  turret 

1.0  scanning 

0.3  tracking 

0.2  creating  impacts 

COMMUNICATE ; 

2.9  communications 

2.7  vehicle-to-vehicle 

0.2  simnet-to-vehicle 


dynamics 

10.3  vehicle  placement 

6.1  acceleration,  etc. 
collision  avoidance 
collision  detection 

8 . 0  other  vehicles 

1 . 2  bounding  volumes 
route  following 

4 . 6  bounding  volume  avoidance 

1.7  choose  velocity 

1.0  station  keeping  lookahead 

0 . 3  close-enough  checks 

0.2  station  keeping  idle 

sending  appearance  packets 


OTHER: 

32.7 


other  functions 


Performance  Optimizations: 

MOVE:  Collision  &  Obstacle  Avoidance 


•  We  use  hybrid  data  structures  for  storing  our  vehicle  information.  They 
are  efficient  for  both  random-access  and  iteration. 

•  We  cache  vehicle  location  information  in  tables  to  eliminate  overhead  of 
sending  messages. 
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SHOOT:  Target  Acquisition: 

There  are  several  levels  of  optimization  performed  to  help  performance. 

Eliminating  L  nnecessary  Inter\isibili(y  Checks: 

•  Cost  of  detection  model  is  in  program-measurement  noise. 

•  Cost  of  intervisibility  calculation  is  not  (mean  of  8.25  msecs). 

•  So,  we  run  the  detection  model  first. 

•  This  saves  lO-35‘5i  of  intervisibility  calculations. 

Optimization  of  Remaining  Inter\isibility  Checks:  Intervisibility  built  on 
top  of  terrain  database  which  is  optimized  for  intervisibility  calculations. 

Terrain  Database  Patch  Ouards: 

•  Patch  guards  are  pre-computed  minimum  and  maximum  elevations  for 
each  500  meter-square  terrain  patch. 

•  These  are  cached,  and  lines  between  eyepoint  and  target  arc  tested  to  see 
if  it  is  necessary  to  check  individual  terrain  polygons. 

•  Their  use  eliminates  50-70%  of  accesses  to  individual  terrain  patches  for 
polygon  intersection. 

Terrain  Database  Patch  Cache: 

•  Individual  terrain  patches,  if  they  must  be  referenced,  are  read  off  disk 
and  are  cached  in  memory. 

•  They  are  flushed  on  a  Least  Recently  Used  bases. 

•  The  hit-rate  for  this  cache  is  highly  variable. 

Simulation  Host  Computer  Cache: 

•  Most  disk  drivers  have  disk  block  caches. 

•  This  can  save  actually  waiting  to  read  magnetic  media. 
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Organization  of  Simhost  Software: 


Simulation 

•  Software  is  written  using  OOP  (‘C’-Flavors). 

-  Multiple -Inheritance  (pre-dates  C++  multiple-inheritance) 

-  Message-Passing 

•  Simulation  is  event-list-based. 

•  Items  in  event-list  are  (Time  Jnstance  Message  Datum)  tuples. 

Portability 

Simulation  runs  on; 

•  Uniprocessors 

•  Multiprocessors  (parallel-processor  suppon  code  is  conditionally  compiled 
using  C  preprocessor  #ifdef  directive).  We  require: 

1.  shared  memory 

2.  read-modify-write  cycle 

3.  UNIX  “fork”-Iike  process  creation  facility 

•  Program  runs  on/has  run  on: 

-  MassComp  5500,  5600  RTU  (System  V  based) 

-  Sun  3/50,3/603/280  SunOS  (BSD  4.1  based) 

-  MIPS  R/2000.  UNIX  (System  V  based  RISC  Machine) 

-  BBN  Butterfly  running  Chrysalis  (Multiprocessor) 

-  BBN  Bunerfly  GP-1000,  MACH  UNIX  (BSD  4.3  based  Multipro¬ 
cessor) 
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Parallelism 


Why  bother? 

•  There  were  no  more  cost-efficient  uniprocessor  solutions  at  the  time  we 
went  to  a  parallel  processing  solution. 

•  Parallel-processors  arc  scalable. 

-  Imponant  for  cost-effective  solution  to  differing  site  performance 
requirements. 

-  Imponant  if  computational  requirements  are  not  known  in  advance. 


What  are  the  issues  in  parallel  processor  perfor¬ 
mance? 

Concurrency  Control: 

Ensures  correct  operation  of  program.  Especially  with  respect  to  I/O. 

Load-Balancing: 

Ensures  efficient  use  of  resources. 

Memory  Contention: 

This  has  proved  to  be  the  most  significant  factor  limiting  scaling-up  in  shared- 
memory'  multiprocessors. 
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SAF  Sinihost  Approach  to  Parallel  Processing 


Concurrency  Control: 

Parallelism  occurs  at  the  instance  level.  Concurrency  is  controlled  on  the 
message  SEND  operation. 

•  Two  Version  Two  Phase  Locking. 

-  Public  and  Private  copies  of  instance  variables. 

-  Locks: 

*  Write 

'  Cenif)  (Read-inhibit) 

'  Read 

•  Allows  many  concurrent  read  operations  with  one  simulaiaiieous  write 
operation. 

Multiprocessor-capable  I  ()  Facilities: 

•  Event-lists 

•  Buffer  Pools 

•  Queues 


-  Fast.  Fixed-length 

-  Slower,  “Infinite’'-length,  doubly-linked 


Load-Balancing: 

•  Mirimal  E)yriamir  I_  r»ad-baJincing. 

•  We  do  not  suppon  object  migration. 

.Vlemon  Contention: 

•  A  given  processing  node  hosts  a  set  of  instances. 

•  A  given  processing  node  has  its  o\v7i  event-list. 

•  Ccnain  information  replicated  on  nodes: 

-  some  terrain  database  information 

-  flavo;  method  lists 

-  vehicle  tables 

•  Cenain  information  distributed  across  nodes; 

-  unit  parameter  databases 

-  activities  definitions 

-  detection,  hit.  and  damage  models 


Using  Geometry  to  Minimize  0(A'‘)  Problems: 

Root  Cause  of  the  0(.V*)  Problems; 


•  A  given  unit  must  check  all  other  units  for  interactions. 

•  Try  to  dynamically  group  vehicles  based  on  spatial  relationships. 

•  Should  make  many  functional  areas  of  the  program  less  expensive. 

-  Intervisibility 

-  Detection 

-  Target  Acquisition 

-  Collisioii  Av  oidance 

-  Indirect  Fire 


Critical  Enabling  Technologies 


•  Critical  enabling  technologies  are  identified  from 
a  top  level  object  oriented  architecture  of  the  domain. 


•  These  technologies  are  of  three  types 

•  Technologies  which  support  the  human  commanders 
cognitive  functions  (monitor,  assess,  predict,  plan,  control). 

•  Technologies  which  support  execution 
(move,  shoot,  communicate,  see). 

•  Implementation  dependent  technologies 

(netv  jrk  communications,  distributed  simulation, 
parallel  processing). 

•  Workstation  based  technologies,  in  support  of  the  commander 

•  Doctrinal  Knowledge  Representation. 

•  Mission  and  Plan  Representation  and  Execution. 

•  Text  Generation  System. 

•  Terrain  Representation  and  ^  ^sonlng. 


•  These  technologies  designed  to  scale  vertically  to  deal  with 
cognitive  functions. 

•  Additional  technologies  deal  with  combinatoric  scaling. 

Advanced  Simulation  Division  l-iKiil  ■ 


D-5^ 


Top  Level  Object  Oriented 
Functional  Architecture 


Tactical  Action  Representation  Language 
(TARL) 

Components 


•  Simple  Frame  Language  (SFL)  for  representation  of 
declarative  knowledge 


•  graphic  editor  for  SFL 


•  Goal  Plan  Procedure  (GPP)  language  for  representation 
of  procedural  knowledge 


•  graphic  editor  for  GPP 
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Knowledge  Representation  Environment 


AF  Knowledge  Base 


Simulation  Objects 
SAF  Agents 
SAF  Missions 


Advanced  Simulation  Division 


-J 

I  »  1 1 1  1^ 


D-59 


u  m 

So 

c  < 

os! 

(0 


D-6n 


D-61 


Advanced  Simulation  Division 


Motivation  for  SFL 
in  Support  of 

Object  Oriented  Simulation 


Symbolics  Flavors  are  a  good  starting  point 


value  restrictions  and  default  values  lead  to  more  expressive  power 


the  KL-ONE  family  of  languages  is  a  natural  candidate 
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KREME 
as  a 

Potential  Candidate 


developed  under  DARPA  sponsorship 


derivative  of  KL-ONE 


provides  concept  and  role  hierarchies 


concept  slots  have  value  and  number  restrictions,  and  default 
values 


provides  a  graphical  editor  for  working  with  large  concept 
hierarchies 


includes  a  classifier 
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Simple  Frame  Language 
(SFL) 


derivative  of  KREME  and  KL-ONE 


concept  slots  have  value  and  number  restrictions,  and  default  values 


includes  the  graphical  editor  for  concepts  and  roles 


provides  instances  of  concepts 


does  not  include  the  classifier 
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Classifier  Issues 


it  would  have  been  nice  to  include  the  classifier  but  it  was  not 
essential  for  development 


porting  and  maintaining  the  classifier  was  judged  to  be  a  black 
hole 


the  classifier  degrades  interactive  performance  of  the  graphical 
editor  in  KREME 
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SFL  Instances 


grounds  instances  as  instances  of  Symboiics  Flavors  for 
performance 


s 


value  restriction  and  number  restriction  and  not  checked 
at  run  time 


provides  standard  Zmacs  editing  of  behaviors  (methods) 
for  concepts 


[ 
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SFL  as  a  Central  Resource 
in 

Semi-Automated  Forces  Development 


the  SAF  agents  are  instances  of  SFL  concepts 

(e.g.  tanks,  tank  platoons  and  companies,  rotor  wing  aircraft) 


so  are  simulation  objects  such  as  the  graphic  overlays 
(e.g.  unit  boundries,  phase  lines,  routes) 


mission  goals  and  procedures  defined  in  the  GPP  language  are 
based  on  SFL  concept  definitions 


text  generation  used  in  OPORD  generation  uses  the  SFL  concept 
hierarchy 
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SFL  as  a  Central  Resource  for  SAF 
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The  Role  of  the 

Goal-Plan-Procedure  (GPP)  Language 
In  SAP 


•  GPP  provides  a  declarative  representation  of  procedural  knowledge 


•  used  in  SAP  to  define  the  contingent  behavior  of  military  units 


•  graphic  editor  provides  a  forum  for  interaction  of  system  developers 
and  subject  matter  experts 
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GPP  as  a  Representation  Language 
for  Military  Missions 


the  objective  of  a  mission  is  the  achievement  of  a  GPP  goal 


the  plan  for  achieving  the  goal  is  a  refinement  of  the  goal  into 
subgoals  and  procedures 


following  the  hierarchy  of  military  units,  goal  refinement  frequently 
includes  assigning  subgoais  to  subordinate  units 


procedures  are  knowledge  level  descriptions  of  how  actions  are  to  be 
executed  in  the  SIMNET  world 
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Tactical  Formations  of  a  Motorized  Rifle  Battalion  (BMP) 
Jhe  Soviet  Army:  Operations  and  Tactics 
FM  100-2-1 
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Deployment  for  Attack  from  the  March 
•The  Soviet  Army:  Operations  and  Tactics 
FM  100-2-1 
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Company  Seize  Objective 
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Company  Seize  Objective 
Precedence  View 


Advanced  Simulation  Division 


Concept 

COMPANY-SEIZE-OBJECTIVE-ERE 
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Concept 

COMPANY-SEIZE-OBJECTIVE 
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Company  Road  March 
Precedence  View 
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GPP  Execution  In  an 
Interactive  Environment 


•  assigning  a  mission  to  a  Semi-Automated  Force  unit  involves  selecting 
a  mission  (goal)  and  assigning  mission  parameters 


•  mission  behaviors  are  contingent  on  events  in  the  simulated  world 


•  user  interaction  to  refine  behavior  will  change  goal/subgoal  parameters, 
activate  alternate  paths  in  the  goal  tree,  or  activate  new  goals 


•  new  goals  may  replace  classes  of  executing  goals  or  execute  in  parallel 
with  them 
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Command  and  Control  Process 
The  Tank  and  Mewhanized  Infantry  Team 
FC  71  - 1J 


TPCDP-IIADIIC 

COMUCER'S  ESTIMATE 

METT-T 

FTOCHXmE 

or  TOE  SITUATION 

Amiysis 

RECCIVC  THE 

MISSION 

MISSICM 

ISSUE  WAPNINC; 

Dopty  j 

CFOBfl 

HAKE  A 

EEVXXQP  COURSES 

TERRAIN 

TOnxiTVE 

cr  ACTION 

AMD 

KAN 

AtKIVSIS  CF  CORSES 

WEATOER 

DJrriATC 

cr  AcncN 

COtfARE  COURSES 

TROOPS 

HCMKi2^/PfU3>AAATiaN 
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TIME 
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DnSNT) 

SUPiRVlSE 

Figiffc  2-1.  Cennand  «id  Control  Proeus. 


IROOP-lASaC  FROCZDURE. 

Itmm  art  a  atriti  of  actions  usad  by  tbs  oonpany  oaoBandtr 
planning,  coordinating,  axocuting,  and  suparvisit^  tactical  opt 
tions.  Ibis  is  a  oontin'jous,  dynanic  proctss  Wiieh  allow  for 
■ost  officiant  usa  of  avail^t  tisa.  All  actions  vithln 
troop-laading  procadist  will  ba  accenplishad  ragardlass  of  tha  mo 
of  tiM  availabla.  lha  goal  is  to  prcvida  your  siterdinatas 
conpany  ordar  within  ona-third  of  tha  wailabla  tiaa,  thus  allow 
your  svterdinatas  two-thirds  of  tha  tiaa  Cor  thair  planning 
praparation. 

Iht  troop-laading  procadiva  it  a  continuous  procass  tdtich  notaally 
bagins  upon  racaipt  of  a  aission  and  ands  tdan  tha  aission  is 
acocBpliahod. 

actions  or  stfps  of  tha  troe^loading  preeadiro  ara  show  in 
figura  2-1.  it  is  critical  to  isidarttand  that  thasa  actions  ara 
continuous  and  ara  not  nacasaarily  accoapliahad  in  tha  ordar  show. 
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SAF  Comand  and  Control 


METT-T  Analysis 

Mission  - - 

Enemy _ 

Terrain  and  Weather  . 
Troops  and  Equipment 
Time  Available 


Mission 


Terrain 
Contour  Lines 


gveriavs 
Unit  boundries 
Phase  Lines 
Control  Points 
Objectives 


■ 
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SAF  Map 


Overlays 


SAF  Commander  Selects  GPP  Mission 
Mission  determines  required  parameters 
Establishes  defaults 
Provides  context  for  FRAGOs 


SAF  Commander  Enters  Mission  Parameters 


Ente*  Objective,  Route,  etc. 

Enter  Times 

Review  and  edit  entered  and  default  values 


xz 


OPORD 

SAF  Commands  for  Subordinate  Units 
SOP  as  Required  by  Mission  Phase 


•  •  • 
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Goal'PIan-Procedure  (GPP)  Language 


GPP  is  a  plan  representation  ianguage 


basic  building  blocks  are  goals,  plans  and  procedures 


at  this  time  there  is  an  isomorphism  between  goals  and  plans 


closely  related  to  ACT1  developed  at  BBN  for  work  done  for  NASA  Ames 
and  PRS  developed  at  SRL 
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in: 


Goals 


•  state  the  objective 


have  preconditions,  achievement  conditions  and  faiiure  conditions 


•  goal  parameters  are  defined  by  an  underlying  SFL  concept 


•  the  underlying  concepts  are  used  to  establish  a  hierarchy  of  goals 
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Plans 


a  plan  Is  a  structure  of  subgoals  and  procedures  to  achieve  a  goal 


a  good  plan  will  deal  with  contingencies 


subgoals  and  procedures  are  linked  by  ’’and”,  ”or"  and  "pstop"  nodes 


the  and/or  graph  determines  execution  sequence  and  success/faiiure 


sibling  nodes  will  execute  In  parallel  unless  restricted  by  temporal 
precedence  links 


subgoals  and  procedures  take  arguments  much  like  lisp  functions 
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Procedures 


provide  basic  progamming  constructs  that  determine  agent  actions: 

•  primitive  action  nodes 

•  non-primitive  action  nodes 

•  controi  nodes 

•  wait  nodes 

•  goal  spawning  nodes 

•  end  nodes  returning  success/faiiure 


procedure  parameters  are  defined  by  an  underiying  SFL  concept 
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Goal  Execution  on  Two  Hosts 


Natural  Language  Generation  Technology 
bridges  the  gap  between 


The  structures  appropriate  to  the  reasoning  of  the  expert 
system  and 


#<COMPANY-WITHDRAW-MARCH  304140017 
((FORMATION  NIL) 

(ROUTE .  #<COMPANY-RTE  304114775>) 

(REAR-GUARD  .  PLATOON3) 

(START-TIME  .  2820512907) 

(WHO .  #<WP-TANK-COMPANY  WP-TANK-COMPANY-503 
327027676>))> 


How  they  can  be  clearly  expressed  to  the  user. 

"AH  TB  withdraws  along  Route  Gamma  from  ES70886  to 
ES701808  at  181548  May.  The  rear  guard  is  3! AH  TB." 
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"Natural  language  generation  is  a  different  matter  from 
simply  having  programs  use  English.... 


'Template*  techniques  depend  for  their  effectiveness  on  a 
tacit  limitation  in  the  number  and  complexity  of  the 
situations  in  which  the  program  will  need  to  use  them. 


That  they  have  been  adequate  up  to  now  for  expressing 
what  programs  have  had  to  say  is  more  of  a  comment  on 
the  simplicity  of  today's  programs  than  on  the  capabilities 
of  template-driven  generation...." 


Natural  language  generation  technology  must  address 

verstilitv.  varying  texts  in  form  and  emphasis  to  meet 
the  enormous  range  of  speaking  situations,  and 

creativity,  the  potential  to  express  any  object  or  relation 
as  a  natural  language  text." 


David  D.  McDonald 
"Natural  Language  Generation" 

AI  Encylopedia 


Natural  Language  Generation  Technology 

is  needed  when: 


•  The  application  task  is  complex 


SAF  Activities:  Planning,  C3I,  Fire  &  Manuever, 
Coordination  &  Syncronization. 


•  The  domain  being  modeled  is  complex 


SAF  Domain:  Realistic  Battlefield  Simulation,  large 
numbers  of  vehicles  and  units  controlled  by  small 
numbers  of  commanders 


•  Textual  requirements  are  demanding 


SAF  Textual  Requirements:  Solder-machine 

communication.  Radio  simulation,  Operations  Orders, 
Contents  of  doctrinal  knowledge  bases 


D-92 


Complexities  in  Natural  Language 


one  avenue  of  approach 
NOT  two  avenue  of  approaches 

— >  Rather  two  avenues  of  approach 

A/47  TB  marches  along  Route  3 

Not  A/47  TB  road  marches  along  Route  3 

— >  Rather  A/47  TB  conducts  a  road  march  along  Route  3 

A/47  TB  is  defending  in  Sector  Alpha. 

Not  A/47  TB  is  offending  in  Sector  Alpha. 

— >  Rather  A/47  TB  conducts  an  offensive  mission  in  Sector 
Alpha 
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SAF  APPLICATIONS  OF  TEXT  GENERATION 


Radio  Messages: 

Spot  Reports 

A! 7 4  TB  has  spotted  a  platoon  of  3  vehicles  at  E700800, 

Fuel  Status  Reports 
A/74  TB*s  fuel  level  is  80%. 

Indirect  Fire  Reports 

A/74  TB  reports  20  rounds  of  point  detonating  mortar  at 
ES700800. 


Operations  Orders 

1.  Situation 

C/1  TB  is  to  the  east  and  its  mission  is  to  attack 
objective  GAMMA  from  ES646905  to  ES758911  at 
141423  Apr.  A/1  BT  is  to  the  south.  B/ITB  and 
HHC/2  are  to  the  east. 

2.  Mission 

D/1  TB*s  mission  is  to  defend  area  of  responsibility 
ALBPH  at  111600  May.  The  approach  route  is  Route 
2  from  ES701811  to  ES725888. 

3.  Execution 
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SPOKESMAN 

Natural  Language  Generation  System 

COMPONENTS 


Text  planner: 

Selects  information  to  be  communicated 
Determines  perspectives  and  rhetorical  organization 
Chooses  the  linguistics  resources  (words,  syntactic 
classes) 


Developed  at  BBN  to  meet  the  demands  of  DARPA's  military 
planning  and  simulation  systems,  such  as  the  AirLand  Battle 
Management  Program  (ALBM)  and  Semi- Automated  Forces 
(SAF)  which  have  complex  world  models  and  strict  textual 
requirements. 


Linguistic  realization  coMPONENT-MumbIe-86: 

Carries  out  the  text  planner's  specifications  to  produce 
the  text 

Ensures  the  text  is  grammatical 

Handles  all  syntactic  and  morphological  decision  making 

Developed  under  DARPA’s  Strategic  Computing  Program  at  MIT 
and  the  University  of  Massachusetts 
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SPOKESMAN'S 

Components  and  Levels  of  Representation 


Application  Program  Objects 


Text  Structure 


♦  ) 

Linguistic  Specification 


T 


Surface  Structure 


1 


Word-stream 
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TEXT  PLANNER  MUMBLE-86 


DATA  DIRECTED  APPROACH 
TO  NATURAL  LANGUAGE  GENERATION 


Data  Directed:  The  content  of  the  utterance  is  provided 
by  the  application  program 

•  More  efficient  at  run  time:  specification  of  content  is  a  by¬ 
product  of  the  application  program. 

•  Takes  advantage  of  the  structures  in  the  expert  system 
which  directly  reflect  the  experts'  high  level  view  of  the  information. 

•  More  efficient  to  build:  uses  domain  model  from  the 
application  program,  rather  than  building  a  separate  one  for  the 
generator. 
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Terrain  Representation 
and  Reasoning 

Requirements 


•  Map-like  display. 

•  Support  terrain  reasoning 

•  Object  oriented. 

•  Network  based. 

•  Fast  drawing  time. 

•  Dynamic. 

•  Cannot  use  polygonal  representation  used  by  SIMNET  CIGs. 
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Terrain  Representation 
and  Reasoning 

Representation 


Diversified  quadtree  for  spatial  relationships. 


•  Terrain  features  stored  in  arrays  as  objects. 


•  Qaudtree  nodes  contain  indicies  into  arrays. 


•  Populated  at  all  levels  down  to  2500  meter  square  patches. 


Variable  resolution  for  terrain  reasoning. 

•  Same  objects  stored  differently  at  different  levels 


•  forest' 


treelines 


trees 


Vertical  scaling  by  using  hierarchies  of  granular  maps. 
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Terrain  Representation 
and  Reasoning 

Diversified  Quadtree 


Low  Resolution 
Terrain 


i 


Quad  Tree 


diiiidiiD 


1 


High  Resolution 
Tenain 


V. 
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Terrain  Representation 
and  Reasoning 

Terrain  Features 


•  Road  network 

•  width,  intersections,  distances 

•  bridges 

•  River  network 

•  width,  intersections,  distances 

•  Water  bodies 

•  boundary  vectors,  poiygons  (drawing) 

•  Treellnes  and  canopies 

•  boundary  vectors,  heights 

•  Buiidings 

•  bounding  voiumes,  height 

•  Contours 

vectors,  elevation 

Advanced  Simulation  Division 


D-lOl 


r 


Semi-Automated  Forces 

The  Combinatorics  of 
Vertical  Scaiing 


•  Orders  of  magnitude  increase  in  numbers  of  BOS,  terrain  size, 
time. 


•  There  exist  three  major  challenges 

•  reduce  computation  required  to  handle  BOS  interactions 
from  N  squared  to  linear. 

•  reduce  computation  required  per  individual  BOS  to 
less  than  linear. 

•  provide  minimally  manned  SAF  command  hierarchy 
with  command  toots  to  handle  increase  in  assets. 


•  Do  so  while  maintaining  physical  integrity  at  the  BOS  level. 


S 
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Activity  Levels  of  BOS 
Depends  on 
Tactical  Context 


Ref  Modelling  and  Simulation  of  Land  Combat 


•  As  scale  of  battle  increases,  percentage  of  BOS  exposed 
to  fire  at  any  one  time  decreases. 

•  Generalized  observation  is  that  as  scale  of  battle  increases 
percentage  of  BOS  involved  In  specific  situations  at  any  one 
time  decreases. 

•  Simulate  BOS  to  a  degree  of  fidelity  suitable  to  the  context. 
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Dynamic  Fidelity  Simuiation 
of 

SAF  BOS 


•  Maintain  physicai  existence  of  SAF  BOS  at  ali  times. 

•  Use  variable  simuiation  tick  rate  to  modify  simuiation  fidelity. 

•  Higher  tick  rate  gives  higher  simulation  fidelity. 

•  Tactics  equivalent  of  the  dead  reckoning  model. 

•  Tactical  behavior  divergence  replaces  dynamics  divergence. 


S. 
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Context  Dependent  Fidelity 


•  A  spectrum  of  fidelity  requirements  exists,  for  example 


high  fidelity 


▲ 


SAF  BOS  In  visual  range  of  manned  BOS. 

SAF  BOS  in  combat  but  out  of  visual  range 
of  manned  BOS. 


•  SAF  BOS  moving,  but  not  in  combat  and 
out  of  range  of  manned  BOS. 


low  fidelity 


SAF  BOS  stationary,  not  in  combat,  and 
out  of  range  of  manned  BOS. 


•  SAF  BOS  in  range  of  a  sensor  which  relays  Information 
directly  back  to  a  human.  Simulation  fidelity  depends  on 
sensor  resolution. 


•  The  above  example  covers  the  basic  tasks  of  move,  shoot, 
communicate,  see. 

•  Can  tailor  simulation  fidelity  to  contexts  of  Interest  to  user, 
I.e.  can  concentrate  on  BFA  of  choice. 
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Feasibility  Caicuiation 
Exampie 


•  Single  SAF  BOS  at  maximum  simulation  fidelity  is  the  baseline. 

•  Four  simulation  fidelity  buckets:  1,  1/5,  1/25,  1/125 

•  Consider  a  5000  vehicle  blue  div  versus  a  15000  vehicle  red  CAA. 


Fidelity  Bucket 

1 

1/5 

1/25 

1/125 

Div 

40% 

30% 

20% 

10% 

5000 

2000 

1500 

1000 

500 

2000 

300 

40 

4 

2344 

CAA 

25% 

25% 

25% 

25% 

15000 

3750 

3750 

3750 

3750 

3750 

750 

150 

30 

4680 

20000 

7024 
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Reduce  Simulation  Requirements 
per  BOS 

to  less  than  Linear 


Assume  conservative  size  of  unit  is  four  times  size  of  subordinate. 

Assume  conservative  distribution  of  unit  BOS  over  simulation 
buckets. 


Simulation  Fidelity 


1 

1/5 

1/25 

Co 

100 

0 

0 

Bn 

75 

25 

0 

Regt 

60 

30 

1  0 

Div 

40 

30 

20 

CAA 

25 

25 

25 

1/125 


Simulation  size/Battle  scale 


Battle  Scale 
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After  Action  Review 


•  AAR  insertion  in  a  taped  battie  wili  iead  to  human  eyeballs 
in  low  simulation  fidelity  areas. 

•  The  AAR  system  must  contain  SAP  code  to  integrate  over 
long  tick  rates  and  produce  intermediate  updates. 

A  smoothing  algorithm. 

•  Use  stored  future  ticks  of  the  BOS. 

•  Use  SAP  unit  missions 


•  SAP  unit  missions  must  be  broadcast  over  the  SIMNET  LAN. 

•  AAR  can  now  analyze  command  decisions, 
not  Just  BOS  behavior. 
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Surge  Conditions 


•  Surge  conditions  can  be  caused  by  high  resolution 
large  footprint  sensors. 

Blue  Forces 


Red  Forces 


Not  Exposed  to  Fire 


Not  Exposed 

^.^Expo  s  e  d 

to  Fire 

to  Fire  > 

Low  Fidelity  / 

Simuiation  / 

High  Fidelity 
Simulation 

Low  Fidelity  Simuiation 


sensor 


Use  smoothing  algorithms  similar  to  AAR. 
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Dynamic  Fidelity  Simulation 
Conclusion 


•  Tactical  context  drives  simulation  fidelity. 

•  Can  tailor  large  scale  simulation  to  concentrate  simulations 
resources  on  BFA  of  interest  to  user. 

•  Simulation  fidelity  varied  by  tick  rate  at  the  BOS  level. 

•  Simulation  assets  per  simulated  BOS  less  than  linear 
with  battle  scale. 
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Situation  Prediction 


•  Must  be  able  to  predict  ahead  of  SIMNET  time 
for  tactical  situations 

•  Critical  tactical  decisions  for  software  subordinates 

to  be  made  by  commander  in  downward  control  mode. 

•  Software  subordinates  must  be  able  to  plan  (under 
supervisory  control  of  human  commander). 

•  Detect  changes  in  tactical  context  which  will  drive  changes 
in  fidelity  of  the  BOS  simulation. 


•  Use  a  fast  look-ahead  ag.iregated  combat  simulator  driven  by  SAP 
missions  (Tactical  Action  Representation  Language)  and  based  on 

SIMNET  situation  as  starting  scenario. 

•  Use  DARPA  funded  ALBM  heuristic  combat  evaluator  (HCE) 
(developed  by  BBN's  SIMNET  team)  as  starting  point 

(shared  ideas  and  development  techniques  lead  to  fast  utilization). 
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Fast  Look’Ahead  Wargamer 
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